Re: autoconf-2.62 doesn't build on RHEL4

[Eric Blake]

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