# Build system support for stock FreeBSD autoconf ports

- Thread: https://externals.io/message/15639
- Original archive: https://news-web.php.net/php.internals/15639
- Started by Jon Parise on 2005-03-27T22:15:33+00:00
- Messages: 21
- Reply by email to internals@lists.php.net
- More for agents: search with https://externals.io/search.md?q={query} · JSON API at https://externals.io/api · documentation at https://externals.io/llms.txt

---

## #15639 — Jon Parise — 2005-03-27T22:15:33+00:00

URL: https://externals.io/message/15639#15639

The attached patch allows PHP's build system to recognize FreeBSD's
"versioned" autoconf ports without the need for system-level symlinks
or similar aliasing.  It uses 'shtool path' to (attempt to) locate the
appropriate autoconf / autoheader executable.

I noticed that Jani did a bit of work earlier this year directed at
simplifying the build system (such that it only uses our bundled
libtool, for example).  Given that, I'm not sure if it is still
acceptable to use shtool to locate external executables, so I'm asking
for a patch review here before committing anything.

Thanks!

-- 
Jon Parise (jon of php.net) :: The PHP Project (http://www.php.net/)

---

## #15648 — Jani Taskinen — 2005-03-29T08:11:27+00:00

URL: https://externals.io/message/15639#15648 · In reply to: #15639

> The attached patch allows PHP's build system to recognize FreeBSD's
> "versioned" autoconf ports without the need for system-level symlinks
> or similar aliasing.  It uses 'shtool path' to (attempt to) locate the
> appropriate autoconf / autoheader executable.

     I added such patch once but Sebastian got some problems with
     it so it was reverted. And I don't want to add this patch
     either unless there is very good reason to do so.

     There are no known problems of running buildconf with
     autoconf 2.13, so why shouldn't that be allowed?
     (it's actually PREFERRED version :)

     And finally: Common users should NEVER EVER run buildconf.

     --Jani
5B

---

## #15653 — Roman Neuhauser — 2005-03-29T11:45:11+00:00

URL: https://externals.io/message/15639#15653 · In reply to: #15648

# sniper@iki.fi / 2005-03-29 11:11:27 +0300:
> 
> 
> > […]
> 
>     I added such patch once but Sebastian got some problems with
>     it so it was reverted. And I don't want to add this patch
>     either unless there is very good reason to do so.

    It would be interesting to know what the problems were so that
    they could be ironed out.

>     And finally: Common users should NEVER EVER run buildconf.

    But why make hacking PHP harder?

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

---

## #15654 — Jani Taskinen — 2005-03-29T12:24:07+00:00

URL: https://externals.io/message/15639#15654 · In reply to: #15653

> # sniper@iki.fi / 2005-03-29 11:11:27 +0300:
> > […]
>
>    It would be interesting to know what the problems were so that
>    they could be ironed out.

     He had the problems with gentoo and it's autoconf wrapper crap.

> > […]
>
>    But why make hacking PHP harder?

     And how is it hard atm to run './buildconf' ??
     If you have autoconf (any version above 2.13 works) installed,
     there are no problems.

     --Jani

---

## #15655 — Roman Neuhauser — 2005-03-29T12:47:58+00:00

URL: https://externals.io/message/15639#15655 · In reply to: #15654

# sniper@iki.fi / 2005-03-29 15:24:07 +0300:
> 
> 
> > […]
> 
>     He had the problems with gentoo and it's autoconf wrapper crap.
> 
> > […]
> 
>     And how is it hard atm to run './buildconf' ??
>     If you have autoconf (any version above 2.13 works) installed,
>     there are no problems.

    I have autoconf-2.13, 2.53, 2.59, automake-1.4.5, 1.5, 1.9.4,
    libtool-1.3.5, 1.5.10. I have no executable named autoconf,
    automake, or libtool, instead, there are autoconf213, autoconf253,
    etc.

    Without symlinking or installing the desired versions somewhere
    and munging PATH, running ./buildconf is an uber-easy way to be
    informed that I don't have the required tools.
    
    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.

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

---

## #15656 — Jani Taskinen — 2005-03-29T13:15:38+00:00

URL: https://externals.io/message/15639#15656 · In reply to: #15655

> # sniper@iki.fi / 2005-03-29 15:24:07 +0300:
> > […]
>
>    I have autoconf-2.13, 2.53, 2.59, automake-1.4.5, 1.5, 1.9.4,
>    libtool-1.3.5, 1.5.10. I have no executable named autoconf,
>    automake, or libtool, instead, there are autoconf213, autoconf253,
>    etc.

     If there are no autoconf/autoheader executables, that's no way
     any PHP problem.

>    Without symlinking or installing the desired versions somewhere
>    and munging PATH, running ./buildconf is an uber-easy way to be
>    informed that I don't have the required tools.

     Life is hard sometimes.

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

     --Jani

---

## #15657 — Sascha Schumann — 2005-03-29T14:46:37+00:00

URL: https://externals.io/message/15639#15657 · In reply to: #15656

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.

     - Sascha

---

## #15658 — Roman Neuhauser — 2005-03-29T14:51:24+00:00

URL: https://externals.io/message/15639#15658 · In reply to: #15657

# 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

---

## #15659 — Sascha Schumann — 2005-03-29T15:15:54+00:00

URL: https://externals.io/message/15639#15659 · In reply to: #15658

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:
> > […]
>
>    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

---

## #15671 — Jon Parise — 2005-03-30T03:43:30+00:00

URL: https://externals.io/message/15639#15671 · In reply to: #15656

> > […]
> 
>     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).

I believe this is a workable, non-intrusive solution that should work
in all environments.

-- 
Jon Parise (jon of php.net) :: The PHP Project (http://www.php.net/)

---

## #15782 — Jon Parise — 2005-04-04T05:35:37+00:00

URL: https://externals.io/message/15639#15782 · In reply to: #15671

> 
> 
> > […]
> 
> 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.

Thanks.

-- 
Jon Parise (jon of php.net) :: The PHP Project (http://www.php.net/)

---

## #15783 — Jani Taskinen — 2005-04-04T06:06:57+00:00

URL: https://externals.io/message/15639#15783 · In reply to: #15782

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



> 
>
> > […]
>
> 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.

---

## #15807 — Joe Orton — 2005-04-05T08:20:17+00:00

URL: https://externals.io/message/15639#15807 · In reply to: #15782

> 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

---

## #15817 — Jon Parise — 2005-04-05T15:11:52+00:00

URL: https://externals.io/message/15639#15817 · In reply to: #15807

> 
> > […]
> 
> I doubt that is portable make syntax.

I only have experience with GNU make and BSD make, and it works under
both of those environments.  Could you suggest a more portable syntax?

-- 
Jon Parise (jon of php.net) :: The PHP Project (http://www.php.net/)

---

## #15882 — Brian J. France — 2005-04-07T00:19:09+00:00

URL: https://externals.io/message/15639#15882 · In reply to: #15782

> 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

---

## #15883 — Brian J. France — 2005-04-07T00:28:24+00:00

URL: https://externals.io/message/15639#15883 · In reply to: #15882

Ok, lets try this:

http://www.brianfrance.com/patch.build

Brian


> 
> > […]
>
> 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

---

## #15889 — Jani Taskinen — 2005-04-07T06:28:27+00:00

URL: https://externals.io/message/15639#15889 · In reply to: #15883

I made some changes to phpize now. But not using your
     patch since that would not have worked everywhere.
     Searching for these tools is _still_ a big no no.
     Just make sure they're in PATH.

     --Jani




> Ok, lets try this:
>
> http://www.brianfrance.com/patch.build
>
> Brian
>
> 
> > […]

---

## #15897 — Brian J. France — 2005-04-07T17:07:44+00:00

URL: https://externals.io/message/15639#15897 · In reply to: #15889

>     I made some changes to phpize now. But not using your
>     patch since that would not have worked everywhere.

Cool, changes look good.  What about getting Jon's original patch and 
this change back ported?

>     Searching for these tools is _still_ a big no no.
>     Just make sure they're in PATH.

I agree and why we keep our own list of internal patches.  It is much 
easier to maintain the search patch then handle the same email (can't 
find autoconf) from a hundred or so of developers we support.

Brian

---

## #15898 — Jani Taskinen — 2005-04-07T20:49:26+00:00

URL: https://externals.io/message/15639#15898 · In reply to: #15897

> 
> > […]
>
> Cool, changes look good.  What about getting Jon's original patch and this 
> change back ported?

     Done.

     --Jani

---

## #15899 — Brian J. France — 2005-04-07T21:11:07+00:00

URL: https://externals.io/message/15639#15899 · In reply to: #15898

Looks like there might be some problems with your patch to phpize.in 
for lines:

+  if ! test -x "$php_shtool path $PHP_AUTOCONF"; then

and

+  if ! test -x "$php_shtool path $PHP_AUTOHEADER"; then

shouldn't those double quotes be back-ticks?

Also echo and here documents are not working on my system (FreeBSD).  
cat seems to work with here docs.

#> bash --version
GNU bash, version 2.05a.0(1)-release (i386-unknown-freebsd4.3)
Copyright 2001 Free Software Foundation, Inc.

Brian



> 
>
> > […]
>
>     Done.
>
>     --Jani

---

## #15900 — Jani Taskinen — 2005-04-07T22:05:21+00:00

URL: https://externals.io/message/15639#15900 · In reply to: #15899

> Looks like there might be some problems with your patch to phpize.in for 
> lines:
>
> +  if ! test -x "$php_shtool path $PHP_AUTOCONF"; then
>
> and
>
> +  if ! test -x "$php_shtool path $PHP_AUTOHEADER"; then
>
> shouldn't those double quotes be back-ticks?

     Actually both.. fixed now.

> Also echo and here documents are not working on my system (FreeBSD).  cat 
> seems to work with here docs.

     Fixed that too. (all branches)

     --Jani