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
