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: Tue, 23 Nov 2021 08:39:19 +0000


> On 22. Nov 2021, at 21:48, Alessio Vanni <vannilla@firemail.cc> wrote:
> 
> "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.
> 

Actually, I wonder why we have a check for uncrustify there at all... it is not 
a build or runtime dep...


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

Attachment: signature.asc
Description: Message signed with OpenPGP


reply via email to

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