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: Alessio Vanni
Subject: Re: From gnunet-bcd to configure.ac
Date: Mon, 22 Nov 2021 21:48:40 +0100
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/27.2 (gnu/linux)

"Schanzenbach, Martin" <mschanzenbach@posteo.de> writes:

> 1. The uncrustify detection is now verbose. configure outputs the
> output of "uncrustify". Can we prevent that? It looks like an error.

You are right, there was an error in the check. I'm not sure what
happened, but AC_CHECK_PROG became AC_CHECK_PROGS (with the final S)
which has different semantics.

> 2. Configure does not find my microhttpd anymore. I am not using a
> --with-* flag and it works fine in master.

I don't know why it happens. In my tests it would always find it without
the --with flag. Does it at least work with the flag on? That would help
pinpointing the issue.  As it is, the check is offloaded to pkg-config,
but maybe there's something amiss that I failed to notice.  I'll look
into it during the week.

> 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).

As far as I recall, Autoconf 2.71 did not introduce anything new, but
mostly removed or deprecated some macros.  Using this configure.ac with
2.69 (which is available even on very old Debian versions, unless we go
back to when 2.69 was first released) should, at best, not be able to
detect if the C compiler supports C99, as 2.71 deprecated (and thus
emits a warning) when standard revision-specific macros are used.  The
normal AC_PROG_CC macro on 2.69 and earlier provides a C89 compiler.
While this might be an issue, it's also true that by the time Autconf
2.69 was around, the majority of compilers supported C99 out of the box,
so unless a peculiar system is targeted, where the user most likely know
what they are doing, the "average user", even on Debian stable, should
be able to compile GNUnet just fine.  It's not the best, I agree, but
it's not as bad as it looks either.

> We may want to stick with "old" macros if it breaks with a significant
> number of users' toolchain(s).

Most macros currently used on master have been around way before 2.69
and I used pretty much only those. If anything, the main incompatibility
might be with Automake (which I forgot to mention in my first mail,
sorry) as it was bumped from 1.9 to 1.11 to remove a couple of
compatibility shims from configure.ac.  Automake 1.11 should be old
enough to be supported even by Debian users, to continue from the point
above.  As such, it shouldn't break too easily under a "traditional"
setup.

> 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?

Right, I forgot to mention this too. Unfortunately I don't know what's
the best way to check for a LaTeX package, so all I could do was to
check for pdflatex and hope the user installed a sufficiently complete
LaTeX system package from their package manager of choice.  I'll try
adding a compilation test at least for the TikZ and qrcode packages, as
those are the ones being used by gnunet-bcd.

Thanks,
A.V.



reply via email to

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