aclocal-1.8/m4_include behaving oddly

[Phil Edwards]

One of the GCC runtime libraries (libstdc++-v3) has for years contained
the following lines in acinclude.m4:

    m4_include([../libtool.m4])
    dnl The lines below arrange for aclocal not to bring an installed
    dnl libtool.m4 into aclocal.m4, while still arranging for automake to
    dnl add a definition of LIBTOOL to Makefile.in.
    ifelse(,,,[AC_SUBST(LIBTOOL)
    AC_DEFUN([AM_PROG_LIBTOOL])
    AC_DEFUN([AC_LIBTOOL_DLOPEN])
    AC_DEFUN([AC_PROG_LD])
    ])

I've been content to ignore them, since I don't understand libtool.
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

On the advice of a colleague, I tried adding "-I .." to the command line.
This worked.

Unless I'm missing some important piece of philosophy, this is also very very
poor behavior.  We've specifically *told* autowhatever to get a file from
".."  and it's definitely doing something with that file (moving it away
leads to file-not-found errors).  But the definitions inside are somehow
being ignored, unless we futz with redundant command line options.

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.  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.


-- 
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