buildconf

php.internals

Patrick Welche

22 years ago
I just cvs update -A a php4 src tree to get php5 (had to checkout ZendEngine2), and assume that the next thing to do is run buildconf. One thing: after the dance of mv ZendEngine2 Zend, future cvs updates are going to miss ZendEngine2 and this will no longer be updated - would a symlink be a better plan? The last line of buildconf 1.62 says: ${MAKE:-make} -s -f build/build.mk AMFLAGS="$automake_flags" ZENDDIR="$ZENDDIR" but % find . -name build.mk -print ./ZendEngine1/build/build.mk ./Zend/build.mk ./TSRM/build/build.mk so, no build/build.mk... (the one in Zend aka ZendEngine2 is old, the other two are the same - presumably its one of those we want) Cheers, Patrick

Jani Taskinen

22 years ago
Do fresh checkout of 'php5' module. You'll get all correct files then, no need to checkout ZendEngine2 separately.. --Jani On Wed, 21 Jan 2004, Patrick Welche wrote:

Patrick Welche

22 years ago
On Wed, Jan 21, 2004 at 10:07:13PM +0200, Jani Taskinen wrote:
> > Do fresh checkout of 'php5' module. You'll get all correct > files then, no need to checkout ZendEngine2 separately..
I'm amazed how much that helped.. Now there is just the following buglet: buildconf: libtool version 1.1380 2004/01/19 04:57:26) 1.5a found. You need libtool version 1.4.3 or newer installed to build PHP from CVS. Thanks, Patrick

Jani Taskinen

22 years ago
On Thu, 22 Jan 2004, Patrick Welche wrote:
>On Wed, Jan 21, 2004 at 10:07:13PM +0200, Jani Taskinen wrote: >> >> Do fresh checkout of 'php5' module. You'll get all correct >> files then, no need to checkout ZendEngine2 separately.. > >I'm amazed how much that helped.. Now there is just the following buglet: > >buildconf: libtool version 1.1380 2004/01/19 04:57:26) 1.5a found. > You need libtool version 1.4.3 or newer installed > to build PHP from CVS.
Yes, you need libtool 1.4.3. (no, 1.5 is not backwards compatible) Or just grab the latest CVS snapshot from snaps.php.net (safest) --Jani

Patrick Welche

22 years ago
On Thu, Jan 22, 2004 at 01:06:11PM +0200, Jani Taskinen wrote:
> > Yes, you need libtool 1.4.3. (no, 1.5 is not backwards compatible)
There is still something strange with buildconf: % make -n -s -f build/build.mk AMFLAGS= ZENDDIR=Zend build/buildcheck.sh buildmk.stamp echo makefile_am_files = Zend/Makefile.am TSRM/Makefile.am > generated_lists echo config_h_files = Zend/acconfig.h TSRM/acconfig.h >> generated_lists echo config_m4_files = Zend/Zend.m4 TSRM/tsrm.m4 TSRM/threads.m4 Zend/acinclude.m4 ext/*/config*.m4 sapi/*/config.m4 >> generated_lists make AMFLAGS= -s -f build/build2.mk Why does build/buildcheck.sh do the dance of copying the contents of libtool.m4 (whose location it guesses - wrongly in my case) into aclocal.m4, instead of letting libtoolize copy libtool.m4 over and automake pop it into aclocal.m4? This presumably would happen during make -f build/build2.mk if buildcheck gave it a chance.. Cheers, Patrick

Jani Taskinen

22 years ago
There's nothing wrong in this. If your autoconf/aclocal/etc. tools are installed correctly, buildconf works fine. Please use the snapshots if you don't know what you're doing. --Jani On Thu, 22 Jan 2004, Patrick Welche wrote:

Patrick Welche

22 years ago
On Thu, Jan 22, 2004 at 04:51:43PM +0200, Jani Taskinen wrote:
> > There's nothing wrong in this. If your autoconf/aclocal/etc. > tools are installed correctly, buildconf works fine. > > Please use the snapshots if you don't know what you're doing.
:-) I have to smile otherwise I would be offended.
> >Why does build/buildcheck.sh do the dance of copying the contents of > >libtool.m4 (whose location it guesses - wrongly in my case) into > >aclocal.m4, instead of letting libtoolize copy libtool.m4 over and > >automake pop it into aclocal.m4? This presumably would happen during > >make -f build/build2.mk if buildcheck gave it a chance..
The above still stands. I would call your use of the autotools unorthodox. libtoolize would pop libtool.m4 either into . or the directory specified in AC_CONFIG_AUX_DIR. OK, you may wish to carry on using a really outdated autoconf which doesn't understand that, but at least letting libtoolize, which knows where to find the libtool.m4, copy it, and then look for it in . is not a bad thing. However, as you then just copy libtool.m4 into aclocal.m4, I don't see why you don't let the autotools just do if for you. It isn't as if you are altering libtool.m4's contents. Your complexity doesn't seem to buy anything other than your comment about libtool 1.5 not being backward compatible. Regards, Patrick

Jani Taskinen

22 years ago
On Thu, 22 Jan 2004, Patrick Welche wrote:
>On Thu, Jan 22, 2004 at 04:51:43PM +0200, Jani Taskinen wrote: >> >> There's nothing wrong in this. If your autoconf/aclocal/etc. >> tools are installed correctly, buildconf works fine. >> >> Please use the snapshots if you don't know what you're doing. > >:-) I have to smile otherwise I would be offended.
=)
>> >Why does build/buildcheck.sh do the dance of copying the contents of >> >libtool.m4 (whose location it guesses - wrongly in my case) into >> >aclocal.m4, instead of letting libtoolize copy libtool.m4 over and >> >automake pop it into aclocal.m4? This presumably would happen during >> >make -f build/build2.mk if buildcheck gave it a chance.. > >The above still stands. I would call your use of the autotools >unorthodox.
I hope you mean "PHP uses" since I have nothing do to with the way they're used. :) And I'm sure Sascha will gladly explain you WHY we use them like we do. (mainly because they suck in so many ways.. :)
>libtoolize would pop libtool.m4 either into . or the directory >specified in AC_CONFIG_AUX_DIR. OK, you may wish to carry on using >a really outdated autoconf which doesn't understand that, but at >least letting libtoolize, which knows where to find the libtool.m4, >copy it, and then look for it in . is not a bad thing. However, as >you then just copy libtool.m4 into aclocal.m4, I don't see why you >don't let the autotools just do if for you. It isn't as if you are >altering libtool.m4's contents.
Actually we should be altering, the snapshots are generated using patched libtool.m4..and I think we should bundle it and append THAT one..Sascha, what's your opinion? --Jani p.s. # cvs log -r1.29 build/build2.mk

Sascha Schumann

22 years ago
> The above still stands. I would call your use of the autotools > unorthodox.
The problem with a number of autotools is that they are unsuitable for large projects which contain a huge number of independent modules. We initially kicked out automake because of that reason and furthermore don't recommend using autoconf 2.50+ (slow, buggy and incomplete, albeit some nice portability work has gone into it). libtool.m4 is copied manually due to removing aclocal (automake tool) from the build chain. I'm not aware of a command to copy libtool.m4 itself. If you want to propose modifications to the current build chain, feel free to post a patch. - Sascha

Patrick Welche

22 years ago
On Fri, Jan 23, 2004 at 08:51:16AM +0100, Sascha Schumann wrote:
> > The above still stands. I would call your use of the autotools > > unorthodox. > > The problem with a number of autotools is that they are > unsuitable for large projects which contain a huge number of > independent modules. We initially kicked out automake > because of that reason and furthermore don't recommend using > autoconf 2.50+ (slow, buggy and incomplete, albeit some nice > portability work has gone into it). > > libtool.m4 is copied manually due to removing aclocal > (automake tool) from the build chain. I'm not aware of a > command to copy libtool.m4 itself.
I see what you mean...
> If you want to propose modifications to the current build > chain, feel free to post a patch.
As mentioned the real culprit was simply the check for libtool.m4 in buildcheck which happens before build2.mk. The following patch essentially moves this check to build2.mk. I have a warning: cat: aclocal.m4: No such file or directory which I don't undersand.. The only line I can think of is from cat acinclude.m4 $$ltfile $$ltsugar > $@ Not a general test, but I can at least build and install php now :-) Cheers, Patrick

Patrick Welche

22 years ago
On Fri, Jan 23, 2004 at 08:51:16AM +0100, Sascha Schumann wrote:
> If you want to propose modifications to the current build > chain, feel free to post a patch.
Enclosed is an even nicer patch. I shouldn't have mentioned the "cat" warning in the previous posting - it has nothing to do with me. Patrick

Sascha Schumann

22 years ago
On Thu, 29 Jan 2004, Patrick Welche wrote:
> On Fri, Jan 23, 2004 at 08:51:16AM +0100, Sascha Schumann wrote: > > If you want to propose modifications to the current build > > chain, feel free to post a patch. > > Enclosed is an even nicer patch. I shouldn't have mentioned the "cat" > warning in the previous posting - it has nothing to do with me.
Please use "diff -u" when creating patches for improved readability. - Sascha