gnunet-developers
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: From gnunet-bcd to configure.ac


From: Schanzenbach, Martin
Subject: Re: From gnunet-bcd to configure.ac
Date: Mon, 22 Nov 2021 19:17:04 +0000

Thanks for the work!

I reviewed the patch/branch and I am having two issues and two comments:

1. The uncrustify detection is now verbose. configure outputs the output of 
"uncrustify". Can we prevent that? It looks like an error.
2. Configure does not find my microhttpd anymore. I am not using a --with-* 
flag and it works fine in master.

Comments:
1. A thing I was wondering is if this autotools version is already "standard" 
(i.e. sufficiently widespread; looking at you debian stable users).
We may want to stick with "old" macros if it breaks with a significant number 
of users' toolchain(s).
2. The "pdflatex detection is reasonable, but unfortunately not sufficient 
which is probably why we didnt do it at all: The latex plugins required are not 
checked.
Maybe the check should actually try to compile a latex file as required by 
gnunet-bcd?

BR

> On 21. Nov 2021, at 20:10, Alessio Vanni <vannilla@firemail.cc> wrote:
> 
> Hello,
> 
> these past few weeks I've been working on a few things summarized by the
> subject of this mail.
> 
> Initially I simply wanted to replace a vector image, but I ended up
> changing a lot more stuff, including doing some major work on the
> configure.ac file.
> 
> It all started when I thought I'd try bringing the cards generated by
> gnunet-bcd more up-to-date with current GNUnet, by changing the old "gnu
> in front of a spiderweb" logo with the new "gnu made by interconnected
> points" logo.
> 
> Before I had started working on that, I had run a test to see how the
> old cards looked like, but I discovered that pdflatex would always abort
> the document generation with some rather obscure errors.  Eventually, I
> discovered that those errors were caused by an incompatibility between
> TikZ 3 and pstricks which, from what I could gather, can't be worked
> around using the methods outlined in the pstricks web page.
> 
> Due to that, other than working on adding the new logo I also had to
> rewrite the TeX files to not depend on pstricks.  Other than generating
> the old logo, it was used to create the QR code with the given GNS URI,
> so I had to search for another package for that task.  It seems the
> "qrcode" package is normally available in a "full" installation of TeX
> as distributed by major GNU/Linux distribution.
> 
> The full details will be listed later in this mail, but eventually I
> managed to rewrite the card-generating TeX file to compile with current
> TikZ and to also have the new logo.
> 
> Since I had changed the whole TeX file, I thought I might as well do the
> rest of gnunet-bcd, in a similar fashion to what I did for the FCFS
> service.
> 
> This resulted in a fairly complete overhaul of gnunet-bcd, which also
> brought a new feature to create a PNG picture of just the QR code, with
> the purpose of letting people easily embed it in other media, instead of
> having to deal with a full-fledged PDF (for example, it can be displayed
> in-line in an e-mail signature.)  Right now it provides only the QR
> code, but since it's a program that come with GNUnet and that can
> connect with GNUnet's services, it can add to the generated PNG as many
> informations as needed.
> 
> Since I had added this feature to generate a PNG, I thought it would be
> nice if gnunet-qr could read the images generated by gnunet-bcd through
> this new feature.  After a bit of work, if GNUnet's configure script
> detects that libpng is available, gnunet-qr will have a new '-f' flag
> which allows the tool to natively read a PNG file and import the scanned
> QR code, if any.
> 
> Incidentally, these changes to gnunet-qr made me discover a bug with
> gnunet-namestore, explained later.
> 
> Lastly, because I had to change configure.ac and since during a system
> update I ended up with Autoconf 2.71 installed, which generated a number
> of warnings when recompiling the configure script, I started working on
> the whole file to not only bring it up to date with the new Autoconf,
> but also to simplify it when possible and correct a few things I have
> always found strange.
> 
> Shortly after writing this mail (it's quite long!), I'm going to push a
> new branch with the following changes:
> 
> - gnunet-bcd
> The new GNUnet logo is now used. This logo is generated through a TikZ
> picture defined in the file itself.
> 
> gnunet-bcd can now generate three different files: the first is simply a
> rework of the file that is already generated; the second is a simplified
> version of that file, in which only the most basic informations, like
> the full name and a few contact addresses, are requested.  The purpose
> of this simplified version is to allow people to generate a "GNUnet
> business card" even when they can't fill most of the fields requested by
> the "full" version.  The last type of file is a PNG-encoded picture of
> the QR code for embedding.
> 
> The web UI has been reworked. It doesn't include the entire Bootstrap 4
> CSS, but contains only the necessary directives, adapted from Boostrap
> 5, to style the used elements (mostly input text boxes and labels.)  The
> main reason for this choice is that editing the previous HTML was fairly
> laborious, as you either deal with a file with a single line of minified
> CSS, something that can kill certain editors, or you use XLSL to
> generate the HTML from an XML specification, which is really an
> unnecessary step, in my opinion.  The maintenance burden is more or less
> the same as before, because unless there's a need to rework the whole
> interface, there's no need to touch the CSS at all.
> 
> It also uses files with similar stylesheets to provide somewhat more
> detailed error pages, instead of giving a very barebones HTML.  This
> last change is really just for consistency with the visuals, as it
> doesn't otherwise bring anything.  Unfortunately to keep things inside
> gnunet-bcd itself simple, most of the CSS had to be duplicated inside
> each file, instead of having them share a single common file, but it
> shouldn't be too much of an issue. In the worst case, the service can be
> made smarter in exchange of more lines of C code.
> 
> Finally, the program itself is not built/installed unless the pdflatex
> tool is available.
> 
> - gnunet-qr
> When libpng is detected by configure, a new option '-f' ('--file') is
> made available, to read a QR code from a PNG-encoded picture.  The
> choice of PNG is really arbitrary, because I believe it's one of the
> best formats for this kind of content, not to mention it's usually
> available everywhere, as sometimes libpng comes already installed when
> installing a GNU/Linux distribution.
> 
> - gnunet-namestore
> The '-u' option was broken. I forgot in which version this change was
> made, but now public keys for egos are "stringified" by prepending a
> readable representation of the string length before the actual key.
> gnunet-namestore was trying to read the old format, which is six
> characters shorter.
> 
> - configure.ac
> For the most part, many macros being used either by the file itself or
> by external files providing macros used by it, were brought up to date.
> For example, iconv.m4 was updated from serial 18 to serial 21 and
> libgcrypt.m4 is now the one released in 2020.
> 
> Some macros were simplified while others were created to reduce the
> amount of repeated code.  This is most notable for checks regarding
> external libraries like libzbar or libmicrohttpd: instead of explicitly
> writing AC_ARG_WITH and do the various checks manually, a new macro
> CHECK_WITH_LIB takes care of that.
> 
> Not every check could be simplified like that, but the amount of code to
> deal with still has been reduced by a decent amount.
> 
> Unfortunately, a few checks had to be made "less simple", due to the
> subject of the checks.  A notable example is 'struct in6_ifreq' which is
> being dealt with through a series of nested AS_IF.  Since the checks are
> meant to provide the proper path to the if_tun.h header (<if_tun.h>
> instead of <net/if_tun.h>, etc.), I couldn't think of a better way.
> 
> Some checks were removed to start transitioning towards Autoconf 2.71.
> Actually, as it is, it's already compatible with 2.71, but I'm not sure
> if it's already fully updated or if Autoconf is being lenient in some
> cases.  I kept 2.69 inside AC_PREREQ just in case.
> 
> The summary printed to screen at the end of the script execution has
> been improved a little, mainly by reordering the entries.
> 
> There are also probably some other things I'm forgetting right now and
> I'm not really going to read the whole git diff.
> 
> This should be everything, so please report any strange behaviour you
> might find.
> 
> Thanks,
> A.V.
> 

Attachment: signature.asc
Description: Message signed with OpenPGP


reply via email to

[Prev in Thread] Current Thread [Next in Thread]