# SNAPS+SNAPSPecl different to Pecl4Win - Thread: https://externals.io/message/30342 - Original archive: https://news-web.php.net/php.internals/30342 - Started by Gaetano Giunta on 2007-06-27T16:57:49+00:00 - Messages: 6 - Reply by email to internals@lists.php.net - More for agents: search with https://externals.io/search.md?q={query} · JSON API at https://externals.io/api · documentation at https://externals.io/llms.txt --- ## #30342 — Gaetano Giunta — 2007-06-27T16:57:49+00:00 URL: https://externals.io/message/30342#30342 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 --- ## #30343 — Gaetano Giunta — 2007-06-27T23:48:06+00:00 URL: https://externals.io/message/30342#30343 · In reply to: #30342 > ... > 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)... --- ## #30345 — Greg Beaver — 2007-06-28T02:05:25+00:00 URL: https://externals.io/message/30342#30345 · In reply to: #30343 Gaetano Giunta wrote: > > > […] > 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 --- ## #30355 — Gaetano Giunta — 2007-06-29T00:19:22+00:00 URL: https://externals.io/message/30342#30355 · In reply to: #30345 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 --- ## #30876 — Gaetano Giunta — 2007-07-12T22:08:48+00:00 URL: https://externals.io/message/30342#30876 I think I finally have something demoable, regarding the possibility of extending pecl4win to offer compiled dlls of the released version pf pecl packages, besides the compiled cvs version. The build process is almost ok: + two separate build environments (incl. pecl trees) are used: one for pecl cvs, one for packaged versions + after pulling via http the released packages from pecl.php.net, if file config.win32 is missing. it is pulled in from cvs. This brought total compiled dll count (for php 5.2.3) up to 38 (there are 3/4 config.w32 files that still need to be patched by hand, but you only have to do it once) + I still have to sort out some troubles in building single extensions... A modified version of the pecl4win site is available here: http://gggeek.altervista.org/sw/pecl4in/ Please note that all links on the pages are broken (no postgres support on that shared host, so I took snapshots of the actual php scripts), you can only access the pages via the main index. It is built on a very small, hand inserted data set, with the only purpose of testing php+sql code. There is a lot more info than before available, but I somehow have the feeling that the disposition is messy. Any suggestion for a better layout/infoset is welcome. Please note that: + page titles / table column headers have been reworked a bit, for greater consistency + the single ext.page layout has seen a column/row swap to accommodate many releases of the same extension + a link back to pecl has been added on the single extension page +++ there is a huge inconsistency between pecl and pecl4win: whereas the former uses the term PACKAGE, the latter uses EXTENSION. Maybe it would be a good idea to fix this? Bye Gaetano ps: I'm still polishing the code, but it is available to everybody who requests it... --- ## #30885 — Richard Quadling — 2007-07-13T09:47:49+00:00 URL: https://externals.io/message/30342#30885 · In reply to: #30876 > I think I finally have something demoable, regarding the possibility of > extending pecl4win to offer compiled dlls of the released version pf > pecl packages, besides the compiled cvs version. > > The build process is almost ok: > + two separate build environments (incl. pecl trees) are used: one for > pecl cvs, one for packaged versions > + after pulling via http the released packages from pecl.php.net, if > file config.win32 is missing. it is pulled in from cvs. This brought > total compiled dll count (for php 5.2.3) up to 38 (there are 3/4 > config.w32 files that still need to be patched by hand, but you only > have to do it once) > + I still have to sort out some troubles in building single extensions... > > A modified version of the pecl4win site is available here: > http://gggeek.altervista.org/sw/pecl4in/ > Please note that all links on the pages are broken (no postgres support > on that shared host, so I took snapshots of the actual php scripts), you > can only access the pages via the main index. > It is built on a very small, hand inserted data set, with the only > purpose of testing php+sql code. > > There is a lot more info than before available, but I somehow have the > feeling that the disposition is messy. Any suggestion for a better > layout/infoset is welcome. > Please note that: > + page titles / table column headers have been reworked a bit, for > greater consistency > + the single ext.page layout has seen a column/row swap to accommodate > many releases of the same extension > + a link back to pecl has been added on the single extension page > +++ there is a huge inconsistency between pecl and pecl4win: whereas the > former uses the term PACKAGE, the latter uses EXTENSION. Maybe it would > be a good idea to fix this? > > Bye > Gaetano > > ps: I'm still polishing the code, but it is available to everybody who > requests it... > > -- > > > > http://gggeek.altervista.org/sw/pecl4win/ if you hadn't already guessed. -- ----- Richard Quadling Zend Certified Engineer : http://zend.com/zce.php?c=ZEND002498&r=213474731 "Standing on the shoulders of some very clever giants!"