Re: bootstrapping CVS libtool

[Scott James Remnant]

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

        AC_LIBTOOL_CONFIG
        AC_LIBTOOL_LINKER_OPTION
        _LT_AC_LANG_C_CONFIG
        _LT_AC_LANG_GCJ_CONFIG
        _LT_AC_LANG_RC_CONFIG
        _LT_AC_PROG_ECHO_BACKSLASH
        _LT_AC_SHELL_INIT
        _LT_AC_SYS_LIBPATH_AIX
        _LT_AC_TAGVAR

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], [])])
        
Scott

[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
    m4ly-correct?

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

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