Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:30355
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 66.249.92.168 as permitted sender)
DomainKey-Status: bad
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=beta;
        h=received:message-id:date:from:user-agent:mime-version:to:subject:references:in-reply-to:content-type:content-transfer-encoding;
        b=GNt9dj/B7+z1/oH/x2Is6jNzuWT3HKspAaJ9FL+JyaxyvCQTgrrWEOtTQS0YY+vwxb9CBCSoOsKdVwdZEYogTYREZIRwz2lvza4a/Q/b0sZm/jLey6xle6gEY2WO+VsV1Eec8mH6KxrTTqkJW33aRQeFKeP5K5YgjBjX8TffvYk=
Message-ID: <4684500A.6050805@gmail.com>
Date: Fri, 29 Jun 2007 02:19:22 +0200
User-Agent: Thunderbird 2.0.0.4 (Windows/20070604)
MIME-Version: 1.0
To: Greg Beaver <cellog@php.net>,  internals@lists.php.net
References: <4682970D.5030607@gmail.com> <4682F736.3030103@gmail.com> <46831765.6000506@php.net>
In-Reply-To: <46831765.6000506@php.net>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: SNAPS+SNAPSPecl different to Pecl4Win
From: giunta.gaetano@gmail.com (Gaetano Giunta)

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
>
>