> On 22. Nov 2021, at 21:48, Alessio Vanni <[email protected]> wrote: > > "Schanzenbach, Martin" <[email protected]> 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. > >> 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. 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 feature. Anyway, the rest LGTM, so feel free to rebase+merge into master whenever. BR Martin > > Thanks, > A.V. >
signature.asc
Description: Message signed with OpenPGP
