autoconf-patches
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [PATCH 1/2] AC_CONFIG_MACRO_DIRS: new macro, mostly for aclocal


From: Gary V. Vaughan
Subject: Re: [PATCH 1/2] AC_CONFIG_MACRO_DIRS: new macro, mostly for aclocal
Date: Wed, 17 Oct 2012 15:25:31 +0700

Hi Stefano,

On Oct 17, 2012, at 2:25 PM, Stefano Lattarini <address@hidden> wrote:
>> based solely on this documentation, that deal with these macro
>> directories.  It would be very bad if we ended up with two tools that,
>> for example, interpreted the directory ordering differently.
> ... but your rationale has convinced me I was wrong.  I will send (later
> or tomorrow) a re-roll with improved documentation.
> 
>> Tools like libtoolize will (again, hopefully) be using this information
>> to decide where to copy libtool macros.  Probably aclocal --install will
>> need to do this as well.  If multiple macro directories are specified,
>> which one should they use?  I think the answer should be: "The first
>> directory in the documented ordering",
> Yes, this is the behaviour I intended to implement in aclocal.

I remember many years ago that Tom Tromey (IIRC) stated that aclocal
was just a stop-gap measure until autoconf could find it's own macros.

I'd *really* like to see aclocal die as a separate program, and have
autoconf look for (and if requested, copy into the project tree) all the .m4
files it needs to generate a configure script.  No need even for aclocal.m4
in that case anymore...  the fewer files and tools we have to teach people
about, the less baroque those people will feel that the Autotools are, and
the easier the GBS is to understand and learn.

I'd have written patches myself long ago, but sadly, Autoconf moved its
implementation to Perl before I had time to do it :(

I think simplifying Autotools to the point where you no longer need to
write a separate bootstrap script to invoke them in just the right order
will be necessary -- just an 'autoreconf' and off you go! :)

Cheers,
-- 
Gary V. Vaughan (gary AT gnu DOT org)


reply via email to

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