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
