autoconf-patches
[Top][All Lists]
Advanced

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

Re: [RFC] Superseding aclocal?


From: Gary V. Vaughan
Subject: Re: [RFC] Superseding aclocal?
Date: Wed, 17 Oct 2012 22:17:05 +0700

Hi Stefano,

On 17 Oct 2012, at 16:45, Stefano Lattarini <address@hidden> wrote:
> On 10/17/2012 11:24 AM, Gary V. Vaughan wrote:
>> On 17 Oct 2012, at 15:52, Stefano Lattarini <address@hidden> wrote:
>>> On 10/17/2012 10:25 AM, Gary V. Vaughan wrote:
>>>> 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.
>>>> 
>>> Me too... But aclocal has existed and been used for so many years now that
>>> I think we can't just make it disappear overnight; we'd need a carefully
>>> crafted, documented and publicized transition plan.  A fist step might be
>>> to move aclocal out into its own git repository, while still distributing
>>> it bundled with Automake (this could be done for Automake 1.14).  But before
>>> starting even to plan for that move, I'd want to be sure that the intended
>>> "replacement" is well underway (that is, designed, agreed upon, and with at
>>> least a semi-working prototype), and that the community is happy with this
>>> transition and committed to help it.
>> 
>> I think there is no need for such a cumbersome transition.  Instead, I would
>> do it like this:
>> 
>>  1. Fold macro search/copy code into autoconf (along with -I argument 
>> support)
>> 
> So autoconf should generate aclocal.m4 itself?  That seems subotimal.

No.  If autoconf can find it's own macros, then there's no need to copy them
(or m4_include them) into aclocal.m4, which is just an historical implementation
detail of pre-2.13 autoconf... it will just load the macro definitions from
wherever it finds them, and (optionally) copy them into AC_CONFIG_MACRO_DIR{,S}
for distribution.

Back in the day, it was easier for Tom to write aclocal inside Automake, which
he already maintained and have it copy all the macro implementations that
Autoconf would need into a file that the existing implementation already reads.

>  I'd
> rather see a clean design in autoconf or even m4 (so done without having to
> worry about backward-compatibility); once that is deployed and working, we
> could separate aclocal from automake, declare it obsolescent, but keep it
> around for backward-compatibility (once we say "this package will no longer
> be updated", it stops being a maintenance burden, so we could keep it around
> indefinitely, as long as people want to use it).

That's true, but orthogonal to teaching autoconf to find macros directly rather
than looking only in aclocal.m4 and having a separate tool to copy stuff there
first.

>>> Honestly, AFAICS, few people complained about aclocal so far (which sadly
>>> can't be said for automake and autoconf).  So aclocal might be annoying for
>>> us to maintain, but doesn't seem a real burden for the users.
>> 
>> Most likely because the folks that complain can't distinguish between
>> where aclocal ends and automake/autoconf begins ;)
>> 
> While that is true, what I meant is that they report issues that have to
> due with their "interfacing" with autoconf and automake (suboptimal or
> unclear syntax, m4 quoting problems, unclear error messages, backward
> compatibility issues) far more often than they report issues having to
> do with aclocal.  Which means that aclocal is fulfilling its role quite
> well; and although we developers would prefer such a role not to even
> exist, that doesn't concern the users very much IMVHO.

ACK.

>> Here's a minimal modernish bootstrap script:
>> 
>>  #!/bin/sh
>> 
>>  autopoint --force
>>  libtoolize --copy --install
>>  aclocal  # m4 dir from ACLOCAL_AMFLAGS
>>  autoconf
>>  autoheader
>>  automake --add-missing --copy
>> 
>> With aclocal search and copy rolled into autoconf, it could look the same,
>> or else like this:
>> 
>>  #!/bin/sh
>> 
>>  autopoint --force
>>  libtoolize --copy --install
>>  autoconf # m4 dir from AC_CONFIG_MACRO_DIR{,S}
>> 
> Then we'd at least need a way to emulate "aclocal --install" in autoconf,
> since having third-party macro definitions distributed for a more reliable
> and predictable build is a feature several users want, independently from
> its "implementation details" (that is, whether such a feature is offered
> by aclocal or autoconf).  And we'd also need to have ACLOCAL_PATH (or an
> equivalent functionality) supported by autoconf ...

Good point.

It looks like the functionality needs to be split between Autoconf and
Automake, since the files that `aclocal --install` copies are partly for 
autoconf,
and partly for the rules Automake writes for make.  Since the two projects
already share some infrastructure, I don't see a problem in having both tools
capable of installing support scripts that they require.

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


reply via email to

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