Re: Which autoconf for libstdc++

[Phil Edwards <phil at jaj dot com>]

On Sat, Dec 20, 2003 at 04:37:54AM -0500, Phil Edwards wrote:
> On Fri, Dec 19, 2003 at 04:49:06PM -0700, Tom Tromey wrote:
> > >>>>> "benjamin" == Benjamin Kosnik <bkoz@redhat.com> writes:
> > 
> > benjamin> Current versions of these tools are
> > benjamin> autoconf-2.59
> > benjamin> automake-1.8
> > 
> > benjamin> If the java and c++ folks agree to this then I guess the
> > benjamin> next step would be to post a RFC on the gcc list, and then
> > benjamin> set AC_PREREQ?
> > 
> > This all sounds good to me.  Let's do it.
> 
> Let's not.  At least not yet.
> 
> I've been trying to convert v3 to use those versions, and some of the new
> behavior is causing problems.  Depending on how easy/hard/possible it is
> to work around them, we might want to standardize on the previous versions.

Some more info:  The current killer is that m4_include has seriously
changed semantics in automake 1.8 (specifically aclocal 1.8, and recall
that "aclocal" is the first command to run when regenerating files).
It used to be that it would simply bring in the included file, using the
include filename, just like "include" works in any other tool.

Current killer example:  our acinclude.m4 contains

 *  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])
    ])

This no longer works.  Or really, the file is read, kindof.  Sortof.
It's read at least in the sense of "if it's not there, a file not found
error is given".  But none of the macro definitions inside take effect.

In order for the file to /really/ be included, you must also pass -I on
the command line.  (I find this phenominally stupid.  If <stdio.h> wants
to contain #include <bits/foobly.h>, then I should not have to compile
with -Ibits to get correct behavior.)

So "aclocal -I .." mostly works, except it still generates complaints
about not seeing some of the macros from that file.

Now in 1.8, instead of being a simple m4 expand-text-as-you-see-it
processor, aclocal wants to be an omniscient database.  Rather than
m4_including other fragments, aclocal simply reads all the *.m4 files it
can find.  The manual deprecates acinclude.m4 and recommends gathering
them all into a subdirectory, which we then scan using "aclocal -I dir".

We did this at one time.  Then we gathered all the fragments into
acinclude.m4 because passing arguments to the autotools was a pain.
During the conversion, I split out parts of acinclude.m4 and configure.ac
into their own fragments.  Benjamin and I thought this might call for
the reintroduction of an "m4" directory.  And now the tools' manual says
the same.  So I tried moving them all into a subdir, removing acinclude.m4,
and testing with

    $ ls m4
    crossconfig.m4  enable.m4  general.m4  linkage.m4  stuff.m4
    $ aclocal-1.8 -I m4 -I ..

but this enters a world of pain with libtool.m4.  "../libtool.m4" can no
longer be found.  Okay, thinks I, it's relative to the including file,
not the current dir, that's normal.  And the including file is now one
level deeper in the tree.  I change it to m4_include([../../libtool.m4]).

Now the file /still/ can't be found, but it's a /different/ error message.
Some /other/ part of the aclocal chain looks for files relative to the
current directory instead of the including file's directory.  Feh.

Okay, I says, aclocal's documentation claims that it looks through all the
.m4 files it can find, and remembers what gets defined in each, and builds
its own little web of dependancies.  If we're scanning the right directories,
we shouldn't need to include any files at all.  I comment out the m4_include.

Bzzt, nope.  Now it can't find it at all.  I think, #@&! it, first just
get it working, then deal with its inadequacies; I copy libtool.m4 from
the top level into the new m4 subdirectory.  No m4)include.  It should
now just be picked up like the rest of the fragments.

Bzzt, nope.  This causes warnings of the form:

    $ aclocal -I m4
    configure.ac:121: warning: AC_PROG_LD is m4_require'd but is not m4_defun'd
    configure.ac:121: AC_PROG_LD is required by...
    m4/general.m4:323: GLIBCXX_CHECK_LINKER_FEATURES is expanded from...
    configure.ac:121: the top level
    $

Except that it /is/ defined.  Right there in libtool.m4.  And --verbose
tells me that yes, it is finding that file.

But it's only a warning.  Finally aclocal.m4 got generated.  Does it work?
No, autoconf complains more about the libtool macros.  Blech.


I am abandoning 1.8 and trying the last of the 1.7.x releases.  More info when
it's available.


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