Re: FUD-Buster: What is PECL, and how does moving stuff to PECL help us with the core?

Yes (and no ;) New win32 build will happily build SAPI from pecl, whereas the unix build requires that the SAPI lives under php-src/sapi. So building a pecl sapi would go something like this (under unix): pear download <name> tar xzf name.XX.tgz -C php-src/sapi cd php-src ./buildconf ./configure .... --Wez. ----- Original Message ----- From: "Eric COLINET" <e.colinet@laposte.net> To: <pecl-dev@lists.php.net> Sent: Wednesday, December 10, 2003 3:34 PM Subject: Re: [PECL-DEV] FUD-Buster: What is PECL, and how does moving stuff to PECL help us with the core? > Hi list, > > And what about SAPI ? > I mean: If someone want to release a custom SAPI could it be done on PECL ? > > > Eric > > At 18:40 09/12/2003, Wez Furlong wrote: > >It seems that most people still don't really get the idea behind > >PECL, and how moving extensions there is a good idea. > > > >Let me spell it out for you: > > > >- PECL provides a way to keep your extensions self contained and > > allows you to keep your own release cycle. > >- In addition, the packaging systems allows you to mark the package > > with explicit, versioned, dependencies. > >- It is very easy to our users to install and upgrade these > > "pickled" extensions. > > > >---> PECL is a great solution for self-contained extensions > > > >How does it help with the core? > > > >- As we move extensions from php-src/ext to pecl/, they can take > > advantage of the PECL infrastructure. > > > > This allows people to build their own PHP and pick and choose the > > particular version(s) of extensions that they want to use. > > They might not want to use the very latest stable version if they > > have a policy for avoiding bugs; conversely, they might want to > > be using the latest version of the extension because it fixes > > some bugs. > > > >What is the resistance to moving stuff from the core? > > > >- PECL is still seen as Siberia. Some developers "fear" that > > putting extensions in PECL will result in them having lower > > quality because PECL extensions are somehow harder to test. > > This is a totally bogus argument. Getting extensions from > > PECL is just as hard or easy as getting anything else from CVS, > > it is just an additional module to check out. There is nothing > > hard about that, unless you are lazy. > > > > The new win32 build system doesn't give a damn about whether > > your extension is in PECL or in the core; it will still compile > > it and run any tests in the test suite; the unix build should > > be able to do this too (currently it is a little painful for > > regular, non-golden extensions, but that shouldn't be hard to fix). > > > >- Some developers simply cannot see that there are two "problems" > > with having our "golden" extensions in PECL: > > > > - Development > > - Packaging > > > > They see them as a combined issue, and get confused about how > > to handle things. > > > > Using appropriate means on the CVS server, we can make the golden > > pecl extensions appear under ext/ at the time you check out the > > sources. Those sources will be HEAD, or whatever other branch > > you requested. Development continues as it always has done in > > the past. > > > > At Packaging time, when the Release Master (lets call him > > Peter Piper) rolls the tarball, he will pick the latest stable > > versions of those golden pecl extensions. > > Typically, these will be the same versions as can be found on > > the current branch, as golden extensions are kept in sync with > > the core; but he may decide to use an older stable version of > > the package if he decides the latest version isn't up to scratch. > > The "pear bundle" tool makes it simple for Peter Piper to > > "pick a pecl". > > > > This approach gives us more flexibility with our releases, without > > overly complicating the common case. > > > > Furthermore, it allows the end user to build their extensions > > as shared modules and then upgrade them to a more recent version > > in between major releases of the core. > > > >I'm tired of hearing FUD about PECL; lets stop resisting it and > >start embracing it. > > > >--Wez. > >"King" of PECL > >(whatever that means) > > > >-- > >PECL development discussion Mailing List (http://pecl.php.net/) > >To unsubscribe, visit: http://www.php.net/unsub.php > > -- > PECL development discussion Mailing List (http://pecl.php.net/) > To unsubscribe, visit: http://www.php.net/unsub.php > > >