Re: [Fwd: autoreconf and aclocal options (-I, --ac-dir)]

[Stepan Kasal]

Hello,
  as a side issue, the following bug was discussed on autoconf-patches.
I'm quoting generously:

On Sun, Apr 02, 2006 at 12:42:50AM -0500, Chris Pickett wrote:
> Stepan Kasal wrote:
> >On Fri, Mar 31, 2006 at 11:25:27PM -0500, Chris Pickett wrote:

> >>I should also add that I have to run autoreconf twice if ACLOCAL_AMFLAGS 
> >>is used to specify the location of the macro dir, but I didn't try with 
> >>the CVS autoconf.
> >
> >I don't understand why this was necessary.
> 
> I think it's to do with generation of aclocal.m4.  It isn't there the 
> first time, and autoconf dies when it can't find AM_PATH_CHECK(), a 
> macro needed to use a locally-installed package.
> 
> $ ls
> configure.ac  Makefile.am  README  src  tests
> 
> $ cat Makefile.am
> ## Process this file with automake to produce Makefile.in
> 
> SUBDIRS = src . tests
> 
> ACLOCAL_AMFLAGS = -I /home/chris/temp/share/aclocal/
> 
> $ autoreconf --install
> Putting files in AC_CONFIG_AUX_DIR, `build-aux'.
> configure.ac:28: error: possibly undefined macro: AM_PATH_CHECK
>       If this token and others are legitimate, please use m4_pattern_allow.
>       See the Autoconf documentation.
> autoreconf2.50: /usr/bin/autoconf failed with exit status: 1
> 
> $ ls
> aclocal.m4      build-aux  configure.ac  README  tests
> autom4te.cache  configure  Makefile.am   src
> 
> $ autoreconf --install
> Putting files in AC_CONFIG_AUX_DIR, `build-aux'.
> libtoolize: `config.guess' exists: use `--force' to overwrite
> libtoolize: `config.sub' exists: use `--force' to overwrite
> libtoolize: `ltmain.sh' exists: use `--force' to overwrite
> configure.ac: installing `build-aux/install-sh'
> configure.ac: installing `build-aux/missing'
> src/Makefile.am: installing `build-aux/depcomp'
> tests/Makefile.am: installing `build-aux/compile'
> 
> $ ls
> aclocal.m4      build-aux    configure     Makefile.am  README  tests
> autom4te.cache  config.h.in  configure.ac  Makefile.in  src
> 
> But, like I said, this is 2.59, maybe it changed.  The placement of the 
> AM_PATH_CHECK() call with respect to AM_INIT_AUTOMAKE doesn't make a 
> difference (I thought it might).

I'm not sure I understand all aspects of this, but I can identify one
issue:
The variable ACLOCAL_AMFLAGS is meant to be used with ``-I relative_dir''.
(See also http://sourceware.org/automake/automake.html#Local-Macros )

I guess I understand your situation:

you are using system-wide Automake together with *.m4 files from packages
installed locally (under your home directory).

You cannot modify the system-wide dirlist file, so you decided to modify
the top Makefile.am of every package.

I don't think this is the best solution possible; it is better to make
a wrapper (or alias) around aclocal (and aclocal-1.x), which would exec
        /usr/bin/aclocal -I /home/chris/temp/share/aclocal $@

I think it would help if aclocal supported an environment variable
ACLOCAL_PATH for this purpose, as I proposed in
http://lists.gnu.org/archive/html/automake/2005-03/msg00051.html

Some do not agree with the proposal, as Ralf Corsepius in the followup
to that proposal.

Some do agree, as the Gnome project.  Their build system uses a
Gnome-specific variable ACLOCAL_FLAGS to fullfill this need.
(See file gnome-autogen.sh in
http://cvs.gnome.org/viewcvs/gnome-common/macros2 )

But for the time being, use the wrapper.

Hope this helps,
        Stepan Kasal