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
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
