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

[Stefano Lattarini]

On 01/27/2013 07:16 PM, Peter Rosin wrote:
> 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?
> 
No, but switching from CVS to a DVCS (git, mercurial, bazaar, whatever)
would make it *easier* for the sluggish project.  Of course, there are
problematic situations preventing a seamless switch, as is the case
with the inter-leaved CVS repositories shared by GCC, binutils, GDB,
whose conversion is going to be a pain (and that is the only reason it
has been put off until now); but those shouldn't be the norm, I think.

>> 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?
>
It must also be said that they switched from Autoconf 2.64 from 2.13:

  <http://sourceware.org/git/?p=binutils.git;a=commit;h=b4857d46>

and never switched to newer Autoconf versions (despite the lack of
backward-incompatibilities in there); so they don't seem particularly
eager of keeping up-to-date with the last autotools releases (I'm not
criticizing these attitude here, just pointing it out).

> 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.
> 
And some have indeed been bad; what I need would be a better way to
judge if a "shoe-grain-moving" trade-off is going to be appropriate
or not.  Getting more and earlier feedback from users and packagers
would help greatly here, but how to assure it will take place?

>>> 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.
>
It should catch those that would cause pain for distro packagers, if we
elicit feedback from them.  And note that I said *at least* a month: I
don't want to make a major release if it hadn't received some feedback
by the packagers this time.

> 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 hope I didn't give the impression of being annoyed at you for speaking
up.  I stressed "me" over "we" just to make clear the AM_CONFIG_HEADER
mess was my fault, and only mine.  The purpose of the "planned backward
incompatibilities" section is exactly to elicit such feedback ...

> 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?
>
The only thing that actually gets removed is depcomp support for the
SGI compiler; that means that automatic dependency tracking will no
longer work with that compiler, but "normal" compilation should still
work, at least until the compiler is supported by Autoconf.  I
should probably fix the NEWS file to make that clear ...

> 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?
>
A recent-ish report (on the Texinfo list) suggested that:

  <http://lists.gnu.org/archive/html/texinfo-devel/2012-11/msg00065.html>

The use of the 'sgi' depcomp resulted in a failed "make all", whereas
with the planned change, it would have succeeded (albeit with dependency
tracking disabled, but that is no issue for a one-shot build).

> Is it intrusive?
>
No, but appeared to be broken, and I didn't judge trying to fix it
a good time investment.  If you are willing to take a shot at doing
the required testing and debugging yourself, I am willing to consider
re-introducing the SGI support (only because the related code is
unobtrusive and "well-insulated").

> What do you gain by the zap?
> 
Not shipping broken code, and not having to debug/fix it for the
benefit of a vanishingly-small user base.

Regards,
  Stefano