Everything

php

Build system support for stock FreeBSD autoconf ports

php.internals

Jon Parise

21 years ago

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

Jani Taskinen

21 years ago

On Sun, 27 Mar 2005, Jon Parise wrote:

> 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

Roman Neuhauser

21 years ago

# sniper@iki.fi / 2005-03-29 11:11:27 +0300:

> On Sun, 27 Mar 2005, Jon Parise wrote:
>
> >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.

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

Jani Taskinen

21 years ago

On Tue, 29 Mar 2005, Roman Neuhauser wrote:

> # sniper@iki.fi / 2005-03-29 11:11:27 +0300:
>> On Sun, 27 Mar 2005, Jon Parise wrote:
>>
>>> 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.
>
>    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.

>>     And finally: Common users should NEVER EVER run buildconf.
>
>    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

Roman Neuhauser

21 years ago

# sniper@iki.fi / 2005-03-29 15:24:07 +0300:

> On Tue, 29 Mar 2005, Roman Neuhauser wrote:
>
> ># sniper@iki.fi / 2005-03-29 11:11:27 +0300:
> >>On Sun, 27 Mar 2005, Jon Parise wrote:
> >>
> >>>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.
> >
> >   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.
>
> >>    And finally: Common users should NEVER EVER run buildconf.
> >
> >   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.

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

Jani Taskinen

21 years ago

On Tue, 29 Mar 2005, Roman Neuhauser wrote:

> # sniper@iki.fi / 2005-03-29 15:24:07 +0300:
>> On Tue, 29 Mar 2005, Roman Neuhauser wrote:
>>
>>> # sniper@iki.fi / 2005-03-29 11:11:27 +0300:
>>>> On Sun, 27 Mar 2005, Jon Parise wrote:
>>>>
>>>>> 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.
>>>
>>>   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.
>>
>>>>    And finally: Common users should NEVER EVER run buildconf.
>>>
>>>   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.
>
>    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

Sascha Schumann

21 years ago

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

Roman Neuhauser

21 years ago

# 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

Sascha Schumann

21 years ago

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

On Tue, 29 Mar 2005, Roman Neuhauser wrote:

Jon Parise

21 years ago

On Tue, Mar 29, 2005 at 04:15:38PM +0300, Jani Taskinen wrote:

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

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

Jon Parise

21 years ago

On Tue, Mar 29, 2005 at 10:43:30PM -0500, Jon Parise wrote:

> On Tue, Mar 29, 2005 at 04:15:38PM +0300, Jani Taskinen wrote:
>
> > >   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.

Thanks.

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

Jani Taskinen

21 years ago

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

On Mon, 4 Apr 2005, Jon Parise wrote:

Joe Orton

21 years ago

On Mon, Apr 04, 2005 at 01:35:37AM -0400, Jon Parise wrote:

> 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

Jon Parise

21 years ago

On Tue, Apr 05, 2005 at 09:20:17AM +0100, Joe Orton wrote:

> On Mon, Apr 04, 2005 at 01:35:37AM -0400, Jon Parise wrote:
> > 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.

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

Brian J. France

21 years ago

On Apr 4, 2005, at 12:35 AM, Jon Parise wrote:

> 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

Brian J. France

21 years ago

Ok, lets try this:

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

Brian

On Apr 6, 2005, at 7:19 PM, Brian J. France wrote: