Re: aclocal-1.8/m4_include behaving oddly

[Phil Edwards]

On Mon, Dec 22, 2003 at 03:17:54PM +0100, Andreas Schwab wrote:
> Phil Edwards <address@hidden> writes:
> 
> > But now we're trying to move to the latest released tools, and aclocal
> > 1.8 flags errors dealing with that block:
> >
> >     aclocal: macro `_AC_PROG_LIBTOOL' required but not defined
> >     aclocal: macro `_AC_LIBTOOL_CXX' required but not defined
> >     aclocal: macro `_AC_LIBTOOL_GCJ' required but not defined
> 
> Which means that you don't have libtool.m4 in $datadir/aclocal.  
> 
> > On the advice of a colleague, I tried adding "-I .." to the command line.
> > This worked.
> 
> Previous versions of aclocal also required this.  If you run aclocal
> 1.7.x with --verbose you will see that it never looks at ../libtool.m4
> unless you pass "-I ..".

So... in fact, it's not been working the way we thought all along?  Ah crumbs.


> > We have tried very hard to avoid requiring developers to pass arguments
> > to the various autotools, largely because there's no way to help them do
> > so automatically.
> 
> What's wrong with "ACLOCAL_AMFLAGS = -I .." in Makefile.am?

Does aclocal pick those out itself, or is that only when rerunning from
a previously-built objdir?


> > And just recently I've been factoring out pieces of our large
> > acinclude.m4 into various smaller .m4 files; if the behavior of
> > m4_include is suddenly different, we'll have to rethink all that.
> 
> There was no change in behaviour.  It only worked before because you
> had the libtool macros installed in $datadir/aclocal.  Presumably you
> are using a different prefix for your automake 1.8 installation, so
> that $datadir/aclocal is empty or does not exist.

I see.  I wonder why the ../libtool.m4 was added then, since we've never passed
-I.. when running aclocal.  Good to know.


Thanks!
Phil

-- 
Debugging is twice as hard as writing the code in the first place.
Therefore, if you write the code as cleverly as possible, you are,
by definition, not smart enough to debug it.
    - Brian W. Kernighan