On Tue, 15 Feb 2005, Zeev Suraski wrote:
At 23:32 15/02/2005, Andi Gutmans wrote:I still think we should reconsider bundling libxml2 and solve this issue. XML is a center piece of PHP 5 and will be more and more used by extensions as well as developers. I think the benefit far outweighs the downside of bundling.
I know some disagree because of size but I don't see this as an issue. I think giving PHP users a better experience is very beneficial.
Andi beat me to it, but I very much think in the same way. If we kept a .tar.gz in CVS of the 'blessed' libxml2 version, that would become a part of the release tarball during makedist, it would have solved this dependency issue once and for all, and ensure that a given version of PHP behaves in the same way (at least as far XML is concerned) everywhere.
Can you explain this a bit more? Like what kind of 'part' will it become?
Is it just copied there in some directory? How is it configured for compile?
etc.
Inside the php-*.tar.gz packages, it would be very much like sqlite or PCRE that we bundle today, except it's obviously a bit bigger and more complex. We'd have to improve the build process to call configure for this library as a part of the standard configure process.
Considering maintenance, which was one of the big downsides of bundling a library (like PCRE/sqlite), instead of replicating the library in our CVS at the file level, we'd put it as a closed .tar.gz package, and update makedist to fetch it and open it into ext/libxml2 or whatever when it creates packages. That would mean that:
1. Developers (those who checkout the source tree) would have to open it on their own, or have PHP use their system libxml2's.
2. Upgrading the version of bundled libxml2 would basically just mean dropping a new .tar.gz of the new libxml2 version in our CVS, and makedist will do the rest.
Zeev
-- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
