Re: bootstrapping CVS libtool

[Gary V. Vaughan]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Scott James Remnant wrote:
| 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).
|
| [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?
|
| 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.

Gah!  That has got to be a bug!!  Otherwise libtool.m4 will be slowly crushed
under the weight of its old releases.

A better algorithm would be to use an existing AC_FOO macro (howsoever it is
defined) in preference to pulling in a new file of macros and all of its
dependencies?

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

Good catch.  Yes, we've been bitten by this before :-(

| 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], [])])
|
| [1] Or we could cheat and rename them, which is why _LT_AC_TAG_CONFIG
|     (was _LT_AC_TAGCONFIG) isn't in that list.

I have been wanting to split libtool.m4 up into several files for a while to
help maintenance, and maybe reduce the size of aclocal.m4 for some of our
users.  Now that libtoolize installs libtool.m4 and ltdl.m4 if they are used,
the trick might be to only show aclocal the local (libtoolize installed)
libtool macros.  I think we should:

~  1: remove $prefix/share/aclocal/l(ibtoo|td)l.m4 of old releases at install
~     time
~  2: keep copies of the latest versions only in $prefix/share/libtool/m4
~  3: maybe we need a new $prefix/share/aclocal/ltcompat.m4 with stubs for
~     the macros you list above to keep aclocal happy?

This will, at least make the next release sane.  Maybe a backport to
branch-1-5 (and branch-1-4?) is also needed to help stem the spread of madness?

Cheers,
        Gary.
- --
Gary V. Vaughan      ())_.  address@hidden,gnu.org}
Research Scientist   ( '/   http://www.oranda.demon.co.uk
GNU Hacker           / )=   http://www.gnu.org/software/libtool
Technical Author   `(_~)_   http://sources.redhat.com/autobook
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.2 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQE/xJFqFRMICSmD1gYRAhm/AJ4gtCg8pwqrZYHWLQxLuOrXk5jmQwCfSXeU
AqRzsqK/eMsZbZgxAZg+N/I=
=y5TA
-----END PGP SIGNATURE-----