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
Do fresh checkout of 'php5' module. You'll get all correct
files then, no need to checkout ZendEngine2 separately..
--Jani
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.mkso, 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
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
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
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
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
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.mkWhy 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
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
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
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
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
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
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
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.
Attached.
Patrick