Re: need to set ACLOCAL_AMFLAGS along with AC_CONFIG_MACRO_DIR

[Stefano Lattarini]

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