* Eric Blake wrote on Wed, Sep 15, 2010 at 10:11:17PM CEST: > At any rate, it seems like maintaining ACLOCAL_AMFLAGS in > Makefile.am is redundant
For simple setups, yes. How common are non-simple setups? I don't know for sure, but I would guess any package with more than a couple of configure scripts might need more than one m4 directory. The GCC and src trees have complex such setups at least. And there might be the odd package where you may *not* want the macro directory automatically included in aclocal -I flags. Or, not at that position in the command line. > - how hard is it to teach automake to have > aclocal _automatically_ include directories mentioned inside > AC_CONFIG_MACRO_DIR, to avoid the dual file maintenance headache? Probably not hard. But duplication exists to also allow complex things, and not make them impossible. How common are packages with not all Makefile.in files generated by automake? More than a few, I'd say, so users need to both adjust SUBDIRS and AC_CONFIG_FILES. Also, it's really helpful for turning a package to (or from) automake file by file. Likewise, merging two packages can be easier when ACLOCAL_AMFLAGS can point to both packages' m4 directories during the process. It's a two-edged sword ... OTOH, we might want to change the default if ACLOCAL_AMFLAGS is not set, to use the AC_CONFIG_MACRO_DIR maybe. That could still help the majority of cases (and avoid needing to think about --install, as that would then not be the default). I think I'd really like a better autoscan, something that sets up or updates a tree's autotools input files in a fairly sane fashion for the most common case. If such a thing is possible. Cheers, Ralf