automake-patches
[Top][All Lists]
Advanced

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

Re: [PATCH 1/5] Drop support for 'configure.in' as the Autoconf input fi


From: Stefano Lattarini
Subject: Re: [PATCH 1/5] Drop support for 'configure.in' as the Autoconf input file
Date: Sun, 27 Jan 2013 18:09:31 +0100

Hi Peter.

On 01/27/2013 12:26 AM, Peter Rosin wrote:
> On 2012-12-29 00:39, Stefano Lattarini wrote:
>> The autoconf input should be named 'configure.ac' instead.  The use
>> of 'configure.in' has been deprecated in Autoconf since at least
>> the 2.13 -> 2.50 transition, and future Autoconf versions (starting
>> with 2.70 probably) will start to warn about it at runtime.  Automake
>> has been warning about it since the 1.13 release.
> 
> Hi Stefano,
> 
> Sluggish projects with the repo in CVS and still using configure.in
> will positively *hate* this change.
>
Do you have any example of such projects in the real world?  That I know
of, there are GNU Binutils and GDB (and related sub-projects possibly);
but they require precise Autotools version AFAIK, and no distro packager
is going to re-bootstrap them with different versions just for fun.

> You are forcing these projects
> to either get a dent in their history or to change tools.
>
This second possibility does actually sound appealing ...

But in practice, "sluggish projects" that I know (e.g., binutils) of are
still using Automake 1.11.1 and Autoconf 2.64 ...

> I suspect distro people will also hate this change, especially so since
> the sluggish projects might just be so sluggish that they stay with older
> tools just because of this change, shifting the burden to the distro
> people. Is the burden for Automake really that large?
>
No, but lots of little burdens make a noticeable one in the end.

> Do you really want to risk rushing out a 1.14.1 reverting the whole
> thing when the pressure starts to build?
>
No; what I want to do this time is wait at least one month before the
first pre-release and the final release, and elicit the feedback of
distro packagers; so that we'll have real data to judge the cost/benefits
of this change.

In addition, the runtime deprecation of configure.in has been in place
since 1.12.x, so that we are not repeating the horrible mistake done
with AM_CONFIG_HEADER were "we" (read: me) went directly from a mere
deprecation in the manual to a complete removal.

Regards,
  Stefano



reply via email to

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