[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: need to set ACLOCAL_AMFLAGS along with AC_CONFIG_MACRO_DIR
From: |
Ralf Wildenhues |
Subject: |
Re: need to set ACLOCAL_AMFLAGS along with AC_CONFIG_MACRO_DIR |
Date: |
Wed, 15 Sep 2010 23:33:13 +0200 |
User-agent: |
Mutt/1.5.20 (2010-08-04) |
* 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