Hello autoconfers and automakers. I have two modest proposals about the issues discussed here. Not sure if they really make sense, though, so criticism is welcome.
On Wednesday 15 September 2010, Ralf Wildenhues wrote:
> * 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.
-*-*-
[Proposal 1]
We can add a new `EXTRA_ACLOCAL_AMFLAGS' special variable for
Makefile.am, whose value is to be *appended* to the automatically
computed ACLOCAL_FLAGS from AC_CONFIG_MACRO_DIR. I have prepared
some test cases to show the behaviour I'd expect from such feature
(see attachements).
-*-*-
[Proposal 2]
We can to add a new autoconf macro (say `AM_EXTRA_ACLOCAL_FLAGS')
which aclocal and automake would trace to fetch extra flags for
aclocal runs (I think this would require the addition, for
consistency, of a configure.ac counterpart for Makefile.am
`ACLOCAL_AMFLAGS' -- maybe `AM_ACLOCAL_FLAGS'?).
If we follow this second route, we could deprecate the user setting
of `ACLOCAL_AMFLAGS' in Makefile.am starting from Automake 1.12,
and remove support for it in Automake 1.13 (this is probably whishful
thinking, though).
-*-*-
**My preference go to proposal 2** (I wrote the tescases referring to
proposal 1 because I hadn't thought yet about proposal 2 when I wrote
them; I'll happily rewrite the tests if there's consensus).
> 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.
This could be done in various ways:
a. A new configure.ac macro akin to `AM_SUBST_NOTMAKE' (this could
work for both proposals [1] and [2] above).
b. A new automake option `no-auto-aclocal-flags' (this also could
work for both proposals [1] and [2] above).
c. If we go with proposal [2], a definition of special variable
`ACLOCAL_AMFLAGS' could simply override the default value that
would be have been computed from the call to the macro
`AC_CONFIG_MACRO_DIR'
d. If we go with proposal [2], a call to macro `AM_ACLOCAL_FLAGS'
could simply override the default value that would be have been
computed from the call to macro `AC_CONFIG_MACRO_DIR'.
> > - 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.
Unless I'm missing something fundamental, the proposals above would
remove the need of duplication, while preserving the possibility of
having more complex setups.
> 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.
This could be easily done with macro AM_ACLOCAL_FLAGS too, right?
> 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
BTW, I don't know how the proposed changes would affect autoreconf.
The fact that they probably would in a non-obvious way is IMHO
another indication that aclocal should really be part of autoconf,
not automake. Oh well.
Regards,
Stefano
aclocal-amflags-1.test
Description: application/shellscript
aclocal-amflags-3.test
Description: application/shellscript
aclocal-amflags-2.test
Description: application/shellscript
aclocal-amflags-4.test
Description: application/shellscript
