As a side note, I've been slowly chugging away (sorry, it's my first php
build on windows ever) on modified pecl4win scripts that would build
extensions starting from pecl releases instead of pulling the code from cvs.
The first problem I have found is that the APC extension (the first I
tested) has no config.w32 file included in the distribution, even though
one is present in CVS (and has been for quite a while afaict).
This prevents a successful build of the extensions under windows (note:
I only tested the php 5 build scripts).
Is this situation common in pecl packages? Is there any (easy)
workaround other than "if the file is not in the distribution, try
getting it from cvs"?
Thanks
Gaetano Giunta
...
The first problem I have found is that the APC extension (the first I
tested) has no config.w32 file included in the distribution, even
though one is present in CVS (and has been for quite a while afaict).
This prevents a successful build of the extensions under windows
(note: I only tested the php 5 build scripts).Is this situation common in pecl packages? Is there any (easy)
workaround other than "if the file is not in the distribution, try
getting it from cvs"?
In reply to my own post: the second package I tested with is runkit.
Unfortunately, version 0.9 (the last available on pecl.php.net) does not
compile with php 5.2.3+ because of a change in
zend_unmangle_property_name. This has been fixed in cvs
(runkit_import.c, on date 26/10/06), but not in any official release.
I am starting to think my approach is fundamentally flawed, if most
extensions will only build on windows when pulled from cvs there is no
usage in trying to compile older releases (and without having even taken
into account the double-life of packages living in both pecl and core)...
Gaetano Giunta wrote:
...
The first problem I have found is that the APC extension (the first I
tested) has no config.w32 file included in the distribution, even
though one is present in CVS (and has been for quite a while afaict).
This prevents a successful build of the extensions under windows
(note: I only tested the php 5 build scripts).Is this situation common in pecl packages? Is there any (easy)
workaround other than "if the file is not in the distribution, try
getting it from cvs"?
In reply to my own post: the second package I tested with is runkit.
Unfortunately, version 0.9 (the last available on pecl.php.net) does not
compile with php 5.2.3+ because of a change in
zend_unmangle_property_name. This has been fixed in cvs
(runkit_import.c, on date 26/10/06), but not in any official release.I am starting to think my approach is fundamentally flawed, if most
extensions will only build on windows when pulled from cvs there is no
usage in trying to compile older releases (and without having even taken
into account the double-life of packages living in both pecl and core)...
Hi Gaetano,
The flaw is not in your system, but in PECL itself. The best approach
here is for authors to ensure their packages are up to date (I don't
intend to single out any folks here, it's not easy to do what I'm
saying). Extensions that don't build simply won't be there. This is
how it works now, except that it is based on CVS rather than on releases.
One can't expect that all old releases will build, there are several
examples of packages at pear.php.net that are so ancient, there was no
proper validation of the package.xml file and they won't install with
newer modern versions of the PEAR installer. This is perfectly natural.
Also, generally there is a lag between CVS and releases for good reason
- further testing of CVS is needed to ensure it doesn't break things.
If there is a pecl4win that shows broken releases, then it puts a useful
pressure on devs to release a new package version. I see no downsides
to your approach.
What may be the best solution is to continue to build from CVS as well,
so we have "snapshots" in a similar manner to PHP snapshots, and releases.
Thanks,
Greg
Thanks for your encouraging words.
I ran a "complete" build today against php 5.2.3, and these are the stats:
-
134 packaged extensions downloaded from pecl website (sniffed the list
out of cvs.php.net, then got the latest existing package for every one)
of those: only 61 have a config.w32 file, while 27 are part of the php
source distribution -
there are 79 folders in the /ext dir of the source distribution, but
only 45 dlls in the windows distribution -
pecl snapshot contains 75 extensions, none of which is part of the 45
dlls in the windows distribution -
pecl4win snapshot contains 94 extensions, 13 of which are distributed
as dlls in the windows distribution and 75 of which are part of the pecl
snapshot ==> pecl snapshot is a subset of pecl4win!
I used the zip.zip file from Edin instead of as a complete build
environment instead of win32build from php.net, and vc++ 2005 express
(so no luck in testing the produced dlls, as they are not compatible
with the official distribution).
Caveats:
- for packages existing both in pecl and in the base distribution, I
compiled the version coming with the distribution - bitset and blenc have errors in config.w32 that prevent building a
correct Makefile. Both have been fixed in cvs, but not (yet) in a release - same goes for cairo_wrapper. Strangely enough, the cvs fix to the
config file dates from november, while the package is from January. Yes,
I am looking at you, Hartmut! ;[ - extensions depeneding on external libs mdbtools, ekhtml and freeimage
have not been built because the libs are missing. BTW: I have downloaded
from sf.net a binary version of freeimage wit .h, .lib and .dll, so that
might (?) be easily solved
Results: 61 dll files built, 43 of which are part of the standard win32
distribution and 29 of which are already in pecl4win
Compared to pecl4win build log, I have to fix a couple of includes (svn,
fbcaccess), plus I lost somewhere all the win32* extensions, so the
final count might be up two or four extensions.
All in all, not a huge sucess, but better than nothing...
Next steps:
- try running the whole process again with php 4.4
- make sure that the db and gui can accomodate both a cvs version and
many packaged versions - ...
- profit!
Hi Gaetano,
The flaw is not in your system, but in PECL itself. The best approach
here is for authors to ensure their packages are up to date (I don't
intend to single out any folks here, it's not easy to do what I'm
saying). Extensions that don't build simply won't be there. This is
how it works now, except that it is based on CVS rather than on releases.
No problem in singling out folks: I can do it myself!
One can't expect that all old releases will build, there are several
examples of packages at pear.php.net that are so ancient, there was no
proper validation of the package.xml file and they won't install with
newer modern versions of the PEAR installer. This is perfectly natural.Also, generally there is a lag between CVS and releases for good reason
- further testing of CVS is needed to ensure it doesn't break things.
If there is a pecl4win that shows broken releases, then it puts a useful
pressure on devs to release a new package version. I see no downsides
to your approach.What may be the best solution is to continue to build from CVS as well,
so we have "snapshots" in a similar manner to PHP snapshots, and releases.Thanks,
Greg