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