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

[Peter Rosin]

On 2013-01-27 18:09, Stefano Lattarini wrote:
> 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.

GGI, it's basically dormant, but it does have a dozen or so configure.in
in CVS. I haven't completely given up on it though even if the word is
out that it's dead, and I know that it's still in use for real things
by others as well. That's just off the top of my head, but I bet there
are lots out there. Probably no high-profile stuff though, but the rest
counts too!

In e.g. the Cygwin case, it is often *required* that packages get
re-bootstrapped for them to work correctly, especially if they have been
bootstrapped with old tools. I even think cygport (the tool used to
package most stuff for Cygwin) by default re-bootstraps packages. I
expect this to hold for other "unstable" platforms as well, but I don't
know how many "fringe" platforms there are out there.

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

Projects go sluggish because people lose interest. If you make it harder
for the sluggish projects, people will lose interest quicker. Is that
what you want?

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

You see, binutils is very active compared to many other projects, and they
still haven't switched to 1.12? How much calendar time was it between
1.12 and 1.13? Not more than a year surely, and that's no time at all.
People just don't upgrade that often, so when someone tries to go from say
1.11 to 1.14 this fall or so they will face difficulties, at least at the
current rate.

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

And you are shifting out your little grains in your own shoes into
the shoes of a lots of package maintainers and distro packagers. You
make it noticeable for all your users instead of the select few actually
looking at the code. I simply question the trade-offs you have made.

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

A month? That will catch approximately zero sluggish projects. What
do you expect? People don't go chasing automake releases just for fun.
They expect them to just work, and consider them not very interesting,
and stick with what they have, which probably work just fine. For them.
If they had some problem with the automake version currently in use, it
has with all likelihood been worked around ages ago, how else would
anybody get any work done at all? I.e., if they have a project depending
on automake...

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

You're the maintainer of this project, I'm just expressing my
thoughts. I.e., I think you are killing compatibility a little bit
too eagerly, and this AM_CONFIG_HEADER instance is not what alarms me,
mistakes happen. What I'm worried about is the longish list of "future
incompatibilities". I haven't read it too carefully, but there seem
to be a lot going on, most of it isn't really that much of a burden
for automake, and this configure.in item will directly affect
a project I'm involved with. So, I'm speaking up.

What is the reason for removing SGI support? To me, the fact
that SGI is dropping its support has absolutely no bearing at all.
Lots of systems are used without support. Is it broken? Is it
intrusive? What do you gain by the zap?

Cheers,
Peter