Re: libxml bundling

On Thu, May 08, 2003 at 05:29:29PM +0300, Zeev Suraski wrote: > At 16:50 08/05/2003, Dan Kalowsky wrote: > >On Thursday, May 8, 2003, at 08:02 AM, George Schlossnagle wrote: > > > >>I agree with Zeev on this. While bundling lack aesthetic appeal (to me), > >>I think it is the only way to address possibly rapidly changing libxml > >>changes, as well as providing support for systems which do not have > >>libxml installed already. > > > >Isn't this the point of having your configure script, to ensure that a > >supported version of an external library is in existence? > > > >I don't buy the argument for supporting systems without a needed external > >library installed. There is plenty of documentation provided already on > >how to configure your PHP build, and more importantly a configure script > >to stop someone who hasn't read it from continuing. > >Is it really the job of PHP to play sysadmin for unix install ABC? > > It's our job to make the installation of PHP as easy and not-time-consuming > as it could possibly be. The whole "whose responsibility is this" approach > is, IMHO, the wrong way to think about it. Requiring the sysadmin to read > docs, bump into configure errors, install/configure additional libraries, > does not fall in the category of being helpful or easy. Bundling it, > does. PHP is not out there to win computer science awards of excellence, > it's there to work and solve problems. I would like to know what it is with this software bundling that is so helpful. I see 4 groups of PHP users (not to mention end users). 1. Those that get PHP binaries from PHP.net, such as the Win32 stuff. 2. Those that get PHP via 3rd party distributions, such as RedHat, etc. 3. Those that compile PHP by hand, but do not develop the software. 4. Those that develop PHP. I'm in all 4 groups depending on the role. Group 1&2 is not affected. Group 3/4 may _have_ do this extra work, before compiling PHP. get libxml2 ./configure make make install Is that so difficult? IMHO, compiling libxml2 is much easier than compiling PHP itself, due to fewer configure options.. So if you can compile PHP you surely can compile libxml2 .. I've only _had_ to compile libxml2 on some old Solaris box the last year or so (all other systems had a package). So that was the only time I had to do it. Not a big deal at all. The real drawback is that with bundling you may very well have multiple libxml2's running inside apache or other web server. YAZ is an example of such a component. Whether YAZ calls the bundled libxml2 or the shared object is difficult to tell. It is asking for trouble. And there will be other components in the future using libxml2 too. PHP people might say now, that we jsut add a PHP configure option to use the bundled of the already installed libxml2... But that's just extra unnecessary complexity , right? We want configure && make on PHP to be determinstic and simple.. -- Adam > The obvious question that comes to mind is "where do we draw the > line?" IMHO, XML is such a basic requirement that this particular case is > a no brainer. I would be pretty aggressive when it comes to allowing > additional bundles - it's no coincidence that we're bundling very few > libraries, and it should stay that way, but built-in XML support should be > one of them. > > >Please note though that while being against bundling, this does not mean I > >am against the idea of fully supporting libxml. > > I was taking that for granted :) > > Zeev > > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: http://www.php.net/unsub.php -- Adam Dickmeiss mailto:adam@indexdata.dk http://www.indexdata.dk Index Data T: +45 33410100 Mob.: 212 212 66