On 08/21/2012 12:20 PM, Paolo Bonzini wrote: > Il 21/08/2012 12:10, Stefano Lattarini ha scritto: >>>> (AC_SUBST): Define AM_VARTYPOS_WHITELIST to "LIBFFI_EXECUTABLE_LDFLAGS >>>> RELOC_LDFLAGS". This is required because Automake-NG is stricter than >>>> mainline Automake in its make runtime checks on possible typos in >>>> variables like 'foo_SOURCES' and 'bar_LDADD', and that was causing a >>>> spurious failure in the GNU Smalltalk build system. >>> >>> Can Automake-NG instead whitelist all-uppercase variables? >>> >> I'd rather not add extra special cases unless that proves to be actually >> necessary. And I believe that is not the case here, since the white >> listing is obtained with just a simple one-liner. >> >> If you really don't like the whitelisting, another viable solution would >> be to rename the RELOC_LDFLAGS variable to, say, RELOC-LDFLAGS, or even >> LDFLAGS.RELOC; and similarly for the other variable. This is the solution >> I'd personally prefer; in the I sent patch I opted for the whitelisting >> just because that entailed less code churn. > > The point is not the whitelisting; it is really that zero code churn is > still the best choice... This smells too much of Autoconf 2.50... I > was there and it was not pretty. ;) > But there is an important difference: Automake-NG is *not* the next version of Automake, it is the "Next Generation": it's not meant to be merged into the Automake code base, nor to supersede Automake, because the two projects have different "mission statement":
- Automake: allow the user to write Makefiles portable to different systems *and* make implementation, and help him to *avoid* using GNU make specific features would hurt portability, - Automake-NG: allow the user to write Makefiles portable to different systems *but* tailored for modern GNU make, and allow them to take *full advantage* of GNU make features whenever possible (which is less than we'd like, due to the code base and design inherited from mainline Automake). Automake-NG might finally supersede Automake when *and if* the great majority of developers using the the Autotools agree that porting to non-GNU make is not worth anymore; but that will not mean that Automake has been merged into Automake-NG, merely that a change in portability requirements have made it obsolete. That's very important to understand. > Another choice is to find AC_SUBSTed variables that end with LDFLAGS, > CPPFLAGS, CFLAGS, etc., and whitelist them automatically. It can be > done in m4, from Automake-NG's macros. > I'm still not sold on this. What if a user have "foobar" in bin_PROGRAMS, and then do something like this in its configure.ac: if something; then AC_SUBST([foobar_LDFLAGS], [-lzap]) else AC_SUBST([foobaz_LDFLAGS], [-lmu]) fi I think a warning about "no program or library named 'foobaz'" is still warranted here. >>> Also, this is different from all other configuration mechanisms; it >>> would be nicer to have it as an Automake-provided AM_* macro, >>> >> Nope, because the whitelisting must be allowed to be Makefile-specific. >> >>> or a Makefile.am definition. >>> >> I agree. And in fact this is exactly the mechanism provided by Automake-NG! > > Doh, obvious when you point it out. :) > >>>> * Makefile.am (AUTOMAKE_OPTIONS): Add the 'ng' option, to ensure that >>>> mainstream Automake is not used by mistake when bootstrapping. Also, >>>> bump the required Automake version from '1.11.1' to '1.12a', which is >>>> the latest (and still development-only) version of Automake-NG at the >>>> moment of writing. Drop the 'dist-xz' option, that is not supported >>>> anymore. The same effect is now obtained ... >>>> (AM_DIST_FORMATS): ... defining this to "gzip xz". >>> >>> Can you instead provide the backwards-compatible format with a >>> deprecation period? >>> >> No, sorry, that would complicate the Automake-NG code for too little >> gain. Automake-NG is actually about "maintainer convenience" as much >> as it is about "user convenience", so such backward-incompatibilites >> and little porting efforts are to be expected when switching from >> mainline Automake to Automake-NG. > > That's fine, indeed if you add support in mainline Automake the > deprecation period would end with the merge of Automake-NG. > But, as I've stressed above, Automake-NG is *not* going to be merged in mainline Automake, ever. The fork has not been thought with that aim in mind. The two projects are meant to co-exists as long as there still are significant client packages that wants to work with non-GNU make implementations (and thus need mainline Automake); when *and if* this portability requirement is finally dropped, Automake will just be abandoned -- not subsumed, not explicitly obsolete; we'll just stop developing and bug-fixing it. >>> And perhaps add support for AM_DIST_FORMATS in mainline Automake? >>> >> This should be easily doable for 1.13, or even 1.12.4. And it might >> help some projects simplifying their transition to Automake-NG. So >> why not? I'll try to cook up a patch in the next days. > (Or I'll accept one, if someone want to beat me at it ;-) > Nice. > > Paolo > Hope I've clarified the situation a bit. Regards, Stefano