Re: autoconf-2.62 doesn't build on RHEL4

[Ralf Corsepius]

On Tue, 2008-04-22 at 07:19 -0600, Eric Blake wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> According to Ralf Corsepius on 4/22/2008 6:36 AM:
> |> |
> |> | ... now, autoconf is forcing me to also ship gm4.
> 
> Which is a good thing for developers.  Anyone actively developing a
> package can be assumed to understand the importance of using working
> tools, and won't mind the extra distribution of gm4 in order to do
> development.  And remember, the audience of developers is MUCH smaller
> than the audience of users.  Whether or not autoconf makes detection of an
> adequate m4 a hard requirement does not change the fact that an inadequate
> m4 produces broken configure files; we chose to make it a hard error
> rather than living with silent breakage, to emphasize this point; but even
> autoconf 2.59, which did not enforce m4 versions, will benefit from having
> a working m4 installed.
> 
> |
> | Requiring (or even bundling) one particular flavor of a shell would
> | likely significantly simply configure scripts :()
> 
> You're comparing apples and oranges. 
I don't see this ... You require a particular version of gm4 instead of
searching for a feasible, sufficient "m4" (note: m4 vs. gm4).


>  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. 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) ...

One could even go one step beyond: Bundle a shell with autoconf and
exclusively use this shell instead of poking around into the system.

> | It's time autoconf dumps using m4 in favor something more stable!
> 
> 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.  But on this
> list, we are sticking with m4 unless you take the time contribute a patch
> that is measurably better, rather than merely griping about the current
> state of things.
:) I had proposed such step many years ago, at times you haven't
probably not even been using autoconf at all.


> | I guess you know how old and broken Cygwin's GCC is?
> |
> | I guess, I'll start to require gcc-4.3.x for my sources, such that
> | Cygwin users will have to upgrade their GCC.
> 
> Apples to oranges again 
?!? Cygwin ships an antiquated, outdated and broken GCC, filled with
tons of known bugs, not supporting many of the features modern GCC
supports. Once packages start to exploit these features, Cygwin will be
out - It's the same result as with autoconf-2.62 on RHEL: Out of
business because the OS is equipped with insufficent tools.


> - supporting multiple compilers from the user's
> perspective is different than requiring particular m4 from the developer's
> perspective.  But yes, you are free to make that move, and when you do
> make it, you can also consider abandoning your use of autoconf (after all,
> once you decide to require a specific compiler of your users, what is left
> for configure to determine about portability?).
A lot. Using autoconf number one task is about checking a system's and
it's tools characteristics/features. 

It would simply abort if a compiler is too antiquated and not providing
required features.

Ralf