[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: CVS libtoolize wants to read unexisting aclocal.m4
From: |
Alexandre Duret-Lutz |
Subject: |
Re: CVS libtoolize wants to read unexisting aclocal.m4 |
Date: |
Sun, 18 Apr 2004 00:28:55 +0200 |
User-agent: |
Gnus/5.1003 (Gnus v5.10.3) Emacs/21.3.50 (gnu/linux) |
>>> "Gary" == Gary V Vaughan <address@hidden> writes:
[...]
>> I feel it might be worth moving away from the traditional
>>
>> fooize # install foo's macros and aux files
>> aclocal
>> autoconf
>>
>> to something like
>>
>> aclocal --copy # copy system-wide macros locally
>> autoconf
>> fooize # install only foo's aux files
>>
>> That way `fooize'-like tools can trace all they want in configure.ac.
Gary> In principle I couldn't agree more... infact, I am in the
Gary> camp that wants aclocal functionality to be rolled in to
Gary> autoconf, and this is a step in that direction.
Gary> Another good thing that comes of this scheme is that
Gary> autoconf can maintain all of the macros it uses (in an
Gary> aclocal-x.y style tree).
Gary> Bad citizens like libtool and gettext would need to
Gary> co-operate with autoconf again about where they install
Gary> their macros, but autoconf could ship a tool that fooize
Gary> installers can use to install their macros.
The day this is done, autoconf will obviously scan
/usr/share/aclocal/ for backward compatibility. Gettext already
install its macros there. IFAICT only CVS libtool doesn't.
As I've already argued in
http://mail.gnu.org/archive/html/libtool/2004-02/msg00014.html
I think this change is a step backward.
If you install *.m4 files in /usr/share/aclocal/ again, you
can already experiment with a `libtoolize --postautoconf'
version of libtoolize that scan libtool from meaningful macros,
and install the necessary auxiliary scripts. That does not need
any other support. Once that is done, it should be easy to
modify autoreconf so it uses this new libtoolize option when
available. (Or perhaps the autoreconf modification can wait
until `aclocal --copy' exists.)
[...]
Gary> What can I do to help it all happen? (I'll get back to m4
Gary> as soon as libtool enters feature freeze for the next
Gary> release).
Nothing is needed in m4 for the above to work.
However, I think we already discussed about the need to
dynamically modify the include search path from inside m4
macros. Such feature is necessary to support
1) parallel/versioned installations
(e.g., multiple automake versions -- this currenlty works
only because aclocal knows the automake version to consider,
but when that functionally is moved over to autoconf we'll
have to indicate the version with a macro)
2) AC_CONFIG_MACRO_DIR
--
Alexandre Duret-Lutz