[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: bootstrapping CVS libtool

From: Scott James Remnant
Subject: Re: bootstrapping CVS libtool
Date: Tue, 25 Nov 2003 16:16:44 +0000

On Tue, 2003-11-25 at 13:27, Gary V. Vaughan wrote:

> Scott James Remnant wrote:
> | The gotcha is that for some reason aclocal pulls in both m4/libtool.m4
> | AND /usr/share/aclocal/libtool.m4 into aclocal.m4 and puts the latter
> | last, so its macros get used.
> This means that aclocal has found a dependency on a macro that is defined in
> /usr/share/aclocal/libtool.m4, but not $top_srcdir/m4/libtool.m4 (m4_defined
> macros can't be seen by aclocal.m4).  If you have time to investigate, it
> would be nice to prevent this happening before we release.
Ok, I've investigated this and I think the problem is that we're
assigning too much intelligence to aclocal :-(

As far as I can tell it has two basic phases:

1) Scan every m4 file and build up a list of AC_DEFUNs (or AU_DEFUN) it
   can find, and remember which file it found them in[0].

2) Scan configure.{ac,in} looking for the name of any macro it saw a
   definition for, pull in the appropriate file and then scan that file
   in the same way (recurse until happy).

This means if you use AC_FOO in m4/libtool.m4 then the first file that
happens to AC_DEFUN that will get included, even though it's defined
with m4_define in that same file.

In other words, anything previously defined with AC_DEFUN in older
libtool.m4 files will need to be defined with AC_DEFUN in later versions
too, including 1.6.

Here's the list of m4_define macros that need to be changed back to
AC_DEFUN simply because they used to be defined with it[1]:


But that's not enough, oh no, precious.  You see, aclocal doesn't know
about macros supplied by Autoconf.  So if we were to define a macro in
an older libtool.m4, say AC_PROG_EGREP, and removed it because it's now
included in the version of Autoconf we AC_PREREQ on, aclocal wouldn't
know about it so would pull in the older libtool.m4 simply because it
defined it.

So in summary, to stop this madness, we need to either change the
definition of the above macro list from m4_define to AC_DEFUN or rename
the macros and then restore the definition of AC_PROG_EGREP even if it's
just a hack like this:

        # AC_PROG_EGREP
        # -------------
        # This is included in Autoconf, but aclocal will pull in an
        # older libtool.m4 unless we AC_DEFUN it *sigh*
        m4_ifndef([AC_PROG_EGREP], [AC_DEFUN([AC_PROG_EGREP], [])])

[0] Interestingly, it doesn't consider 'dnl' to be a comment and if you
    do 'dnl AC_DEFUN([FOO])' it considers that a valid definition of
    'FOO'.  It does ignore '## AC_DEFUN([FOO])' though, is this

[1] Or we could cheat and rename them, which is why _LT_AC_TAG_CONFIG
    (was _LT_AC_TAGCONFIG) isn't in that list.
Have you ever, ever felt like this?
Had strange things happen?  Are you going round the twist?

Attachment: signature.asc
Description: This is a digitally signed message part

reply via email to

[Prev in Thread] Current Thread [Next in Thread]