[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: |
Gary V . Vaughan |
Subject: |
Re: CVS libtoolize wants to read unexisting aclocal.m4 |
Date: |
Wed, 14 Apr 2004 16:13:21 +0100 |
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On 14 Apr 2004, at 12:10, Alexandre Duret-Lutz wrote:
"Gary" == Gary V Vaughan <address@hidden> writes:
Gary> On 13 Apr 2004, at 22:07, Alexandre Duret-Lutz wrote:
Ahem... libtoolize should be called before aclocal, and yet it
tries to reads the file produced by aclocal...
Gary> It can't run autoconf --trace, and needs to see whether libltdl
is
Gary> used, where the macro directory is etc. I think it is okay to
look
Gary> in aclocal.m4 if it is there, I just hadn't discarded the error
Gary> message properly until libtool--devo--1.0--patch-44.
It's probably useful only when aclocal is not used (i.e.,
aclocal.m4 is handmade). Otherwise aclocal.m4 will be a
collection of m4_include from which you won't learn anything.
Yes, and when used in conjunction with automake < 1.8... libtool claims
to support automake >= 1.4p6!!
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.
In principle I couldn't agree more... infact, I am in the camp that
wants
aclocal functionality to be rolled in to autoconf, and this is a step in
that direction.
Another good thing that comes of this scheme is that autoconf can
maintain
all of the macros it uses (in an aclocal-x.y style tree). Bad citizens
like
libtool and gettext would need to co-operate with autoconf again about
where
they install their macros, but autoconf could ship a tool that fooize
installers can use to install their macros.
(Actually the `--copy' thing does not exist yet, but whether the
macro is inserted in aclocal.m4 or installed in the tree and
m4_included makes no difference for this scheme.)
Removing the distinction would make for a more robust toolkit for sure!
You have my buy in. What can I do to help it all happen? (I'll get back
to m4 as soon as libtool enters feature freeze for the next release).
Cheers,
Gary.
- --
Gary V. Vaughan ())_. address@hidden,gnu.org}
Research Scientist ( '/ http://tkd.kicks-ass.net
GNU Hacker / )= http://www.gnu.org/software/libtool
Technical Author `(_~)_ http://sources.redhat.com/autobook
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.2 (Darwin)
iD8DBQFAfVUVFRMICSmD1gYRAhx1AJ9NJ3S8IjyvCkpTNOFJxVRn/NHsVQCgovZ7
qWXwS2ovK0smHtkQ3qGOdD0=
=Wpk5
-----END PGP SIGNATURE-----