Ralf Corsepius <rc040203 <at> freenet.de> writes: > > Requiring a particular shell would > > mean that ./configure is no longer the first step of a user's experience - > Absolutely not. > > ./configure's 1st job would be to find it's shell and then to perform > it's other duties.
Yes, that has been the status quo of ./configure scripts for several years now, first finding a shell that can then execute the rest of configure. > The only difference to current autoconf would be it > not having to mess around with the brokenness of arbitrary shell (Such > as ash on Cygwin, zsh on OSX, dash on Ubuntu) ... Cygwin uses bash, not ash, for several years now. But as there is no single shell that is universally installed across all viable platforms that configure is designed to target, there is no one single shell that configure can search for, rather it must search for any one of a number of adequate shells that can perform the subset of portable operations it uses. > > One could even go one step beyond: Bundle a shell with autoconf and > exclusively use this shell instead of poking around into the system. You've got this wrong. Bundling a shell with autoconf might "help" developers, but it would not help users, unless autoconf forces all projects to ALSO bundle a shell with their configure script. Plus you would be introducing a chicken- and-egg scenario - how do you get the user to configure and install the bundled shell so that they can then run their configure script using the bundled shell? You appear to be confused on a major premise of autoconf - there are two classes of computer users: developers (those who run autoconf, and need extra tools like gm4 installed) and users (those who run configure but not autoconf, and don't need extra tools). It is configure, and not autoconf, that has to jump through hoops to find an adequate shell, because running configure on an arbitrary shell is for the benefit of users, not developers. Requiring an adequate version of m4 for the developers does not violate this premise, since the developer's installed tools have no bearing on what the user needs to successfully run configure. > > Go ahead - this is open source, so you are free to implement your own > > program that does just that, and it won't hurt our feelings. > :) I had proposed such step many years ago, at times you haven't > probably not even been using autoconf at all. Then where's your patch? :) Without tangible evidence of a better way, all the talk in the world won't outperform something that actually does the intended job, however painful it is for you to use the existing tools. > > It would simply abort if a compiler is too antiquated and not providing > required features. Which is exactly what autoconf 2.62 does (in this case, the compiler is m4, and the output is a configure script, rather than an object file). Developers who want to use the latest and greatest features must install the prerequisites independently of the LTS distros, and developers who want to continue developing on LTS distros need not use autoconf 2.62 features until the LTS distro catches up, even if that is years away. It doesn't hurt our feelings if people want to stay stuck in the past - we are not forcing you to use autoconf 2.62. Likewise, it does not hurt my feelings if you want to make your packages require newer gcc features to allow compilation; in the case of cygwin, it will mean that the cygwin distro will continue to ship older versions of your package until the distro's gcc version is updated, that motivated users will manually install the necessary prerequisites to self-compile the newer version without waiting on the distro, and hopefully that more people will be encouraged to contribute to the (ongoing) efforts of porting a newer gcc to the distro. -- Eric Blake
