bug-autoconf
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: autoconf-2.62 doesn't build on RHEL4


From: Eric Blake
Subject: Re: autoconf-2.62 doesn't build on RHEL4
Date: Wed, 23 Apr 2008 06:11:06 -0600
User-agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.12) Gecko/20080213 Thunderbird/2.0.0.12 Mnenhy/0.7.5.666

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

According to Ralf Corsepius on 4/23/2008 2:44 AM:
|> Really, we require newer m4 because older versions caused autoconf to
|> create erroneous configure scripts, and those errors were very difficult
|> to diagnose.  Not to make life harder for you.
| It might be inconvenient to you but reality simply is as simple as:
| Autoconf-2.62 has proven to miss its objective: portability.

Wait a minute.  You are still mixing apples and oranges.  Autoconf's
objective is to output portable configure scripts, and this triumphs over
any concerns about being portable itself.  The reason that Autoconf itself
uses non-portable tools such as new enough GNU m4 and perl, in spite of
the GNU Coding Standards stating that these tools are not to be used in
building portable programs, is that it was decided long ago that
developers are smart enough to install proper prerequisites if they want
to then generate something that DOES comply with GCS for their end users.

Until you understand this paragraph in the manual, you will not understand
why we are not at all worried about requiring an adequate m4 as a
prerequisite to running autoconf:

|    Those who do not understand Autoconf are condemned to reinvent it,
| poorly.  The primary goal of Autoconf is making the _user's_ life
| easier; making the _maintainer's_ life easier is only a secondary goal.
| Put another way, the primary goal is not to make the generation of
| `configure' automatic for package maintainers (although patches along
| that front are welcome, since package maintainers form the user base of
| Autoconf); rather, the goal is to make `configure' painless, portable,
| and predictable for the end user of each "autoconfiscated" package.
| And to this degree, Autoconf is highly successful at its goal -- most
| complaints to the Autoconf list are about difficulties in writing
| Autoconf input, and not in the behavior of the resulting `configure'.
| Even packages that don't use Autoconf will generally provide a
| `configure' script, and the most common complaint about these
| alternative home-grown scripts is that they fail to meet one or more of
| the GNU Coding Standards that users have come to expect from
| Autoconf-generated `configure' scripts.

http://www.gnu.org/software/autoconf/manual/autoconf.html#Introduction

- --
Don't work too hard, make some time for fun as well!

Eric Blake             address@hidden
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (Cygwin)
Comment: Public key at home.comcast.net/~ericblake/eblake.gpg
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAkgPJ1kACgkQ84KuGfSFAYB2TACgzmHCQS9bKW403YSuDXron6A7
M5EAn2ORIzhbEJtJK50OCr64v2MmuPGx
=FPHJ
-----END PGP SIGNATURE-----




reply via email to

[Prev in Thread] Current Thread [Next in Thread]