Yes, use different install prefixes.

 /opt/autoconfX.XX
 /opt/autoconfY.YY

 And add the suitable prefix to your PATH.

 But don't change the names of the utilities..

 - Sascha

sascha@schumann.cx / 2005-03-29 16:46:37 +0200:

The way some systems start to treat autoconf (installing
multiple versions in an absolutely braindamaged way) is not
something we should support.

I suggest whoever is bothered by FreeBSD doing stupid things
should go to the ports maintainer and complain to him.

What's so stupid about it? Can you suggest a way different
versions of autotools could coexist?

--
How many Vietnam vets does it take to screw in a light bulb?
You don't know, man. You don't KNOW.
Cause you weren't THERE. http://bash.org/?255991

 The patch is fine by me. It's very good idea too since
 it's not likely to break anyone's build whatever versions
 they have installed. :)

 Just commit. (or if you can't, I'll do it later today)

 --Jani

Such schemes are quite common thanks to incompatibilities between
autotools versions, e. g. Subversion's buildconf equivalent accepts
the names from environment, mentioning IIRC Debian installing the
tools as e. g. autoconf-213.

If someone can provide a patch that works in every single OS
with any possible combination of autoconf* packages installed I'll
be happy to commit such patch. As long as nobody can provide such patch
and PROVE it won't break things for others -> no commit.

I've read the comments and generated a second patch. This one solves
my problem in a more acceptable way, by introducing two environmental
variables, PHP_AUTOCONF and PHP_AUTOHEADER, which default to 'autoconf'
and 'autoheader', respectively. The idea is borrowed from Subversion's
buildconf equivalent (which Roman mentions above).

Apologies if this got lost amongst the effort to prepare the recent
set of releases, but I'm curious whether or not people find my second
patch acceptable, based on the results of the prior discussion. If
not, I'll know to abandon the issue.

Index: build/build2.mk

RCS file: /repository/php-src/build/build2.mk,v
retrieving revision 1.35
diff -u -r1.35 build2.mk
--- build/build2.mk 3 Feb 2005 17:42:42 -0000 1.35
+++ build/build2.mk 30 Mar 2005 03:36:08 -0000
@@ -32,6 +32,9 @@

targets = $(TOUCH_FILES) configure $(config_h_in)

+PHP_AUTOCONF ?= 'autoconf'
+PHP_AUTOHEADER ?= 'autoheader'

I doubt that is portable make syntax.

joe

Apologies if this got lost amongst the effort to prepare the recent
set of releases, but I'm curious whether or not people find my second
patch acceptable, based on the results of the prior discussion. If
not, I'll know to abandon the issue.

Here is a patch that we plan on using at work (Y!). This patch has two
key additions to Jon's patch. The first I think should be added to
Jon's patch so that shared extensions (phpize) build with his
environment variable change and the second is a change so we don't have
to set environment variables and it will pick up the right files. The
second change may or may not make it in, but I think the first one
should.

The first change is in scripts/phpize.in where it tests and set
PHP_AUTOCONF/PHP_AUTOHEADER variables, then uses them below. This
patch should be added without the:

• if ! which $PHP_AUTOCONF; then

•  PHP_AUTOCONF=`ls -1 /usr/local/bin/autoconf* | sort -r | head 
  

-1`;

•  PHP_AUTOHEADER=`ls -1 /usr/local/bin/autoheader* | sort -r | 
  

head -1`;

• fi

block in it (which would be part of the second change).

The second changes are the ones that do a which command to see if
PHP_AUTOCONF/PHP_AUTOHEADER is really valid and if not try to find the
valid one. I don't know how compatible this is across os's and is the
reason I can see it not making it (but it works for us). This package
also allows us to use any version of the ports/autoconf package without
having to set environment variable.

Let me know what you think.

Thanks,

Brian