[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.
>
signature.asc
Description: Message signed with OpenPGP