[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

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

to something like

       aclocal --copy # copy system-wide macros locally
       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).

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

Version: GnuPG v1.2.2 (Darwin)


reply via email to

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