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