[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: From gnunet-bcd to configure.ac
Re: From gnunet-bcd to configure.ac
Mon, 22 Nov 2021 21:15:32 +0000
> On 22. Nov 2021, at 21:48, Alessio Vanni <firstname.lastname@example.org> wrote:
> "Schanzenbach, Martin" <email@example.com> 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.
Yes, it works with --with-microhttpd. Maybe it is a problem with my system and
there may be some side effects when switching branches.
My mhd is also in an odd location.
>> 1. A thing I was wondering is if this autotools version is already
>> "standard" (i.e. sufficiently widespread; looking at you debian stable
> 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"
Sounds good to me, then! The faster we get it into master, the better then.
>> 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.
Yeah that would be great. OTOH, I am also not sure of this is a must have
Anyway, the rest LGTM, so feel free to rebase+merge into master whenever.
Description: Message signed with OpenPGP