On Mon, Feb 13, 2017 at 11:25 AM, Nick Kew <n...@apache.org> wrote: > On Mon, 2017-02-13 at 08:35 -0800, Luke Perkins wrote: >> Stefen, >> >> I submitted a patch request to the APR README regarding the TARBALL vs. SVN >> versions of the source file a couple of weeks ago. I have not heard back >> from the APR committers regarding the information I needed to successfully >> build APR from SVN trunk. The patch request had to do with specifying >> libxml2/expat to successfully build APR from the SVN trunk. This extra step >> is not required in the APR TARBALL release. > > Sorry about that. I guess noone had a round tuit. Always worth > a followup if it's important.
Likewise. This is neglected but on several of our radars, the submission is most appreciated. >> Can someone explain the differences between expat and libxml2? I built my >> version of APR using libxml2 (2.9.4). Should I have used expat? Is there an >> advantage of one over the other. > > APR's needs are simple, and either will do the job. Originally > it used expat: you had no choice. > > The difference is that libxml2 is much bigger, and does a lot more. > It is required for many applications, such as running HTTPD with > a module such as mod_proxy_html or mod_transform (for XSLT). > In such cases, it makes sense to build APR with libxml2, > because otherwise you'll need to load both XML parsers at once! > That's why we added the libxml2 option. > > If your apps don't require libxml2, it probably makes no difference. > It won't affect performance one way or the other, unless perhaps > in extreme embedded situations where every byte counts! Contrawise, some apps require expat, specifically. The Subversion package is one example that was just brought to my attention. There will be builds and deployment scenarios that will continue to require both expat and libxml2 for a long time to come. Thankfully, these two components do not clash. I'm curious if we've had a chance to benchmark the performance differences between these two deployment options for core apr-util operations? > As for expat upgrade, ideally it would make more sense to unbundle it > from future tarballs. But that's another argument. The project committee voted and elected to no longer distribute this dependency in the distribution source package from the ASF. It will no longer be present in apr-util 1.6.0 distribution, nor in apr 2.0.0 (where apr-util becomes one part of the singular apr source distro.) It no longer resides in our svn source repos of these next releases, and in-tree expat has been unbundled from the autoconf scripts IIRC. The most important reason we will no longer distribute dependencies such as expat is that any substantial change, such as Expat 1.9.5 to 2.0.0 to 2.1.0 to 2.2.0 are enhancement cycles or may represent binary breaking changes; we cannot be bound to any third party author's versioning calendar. We also do our users a disservice by shipping out-of-date code. Expat wasn't so widely adopted when we launched the APR library, and we wanted to help our early adopters; today expat is deployed on most any *nix distribution. As Nick suggests, apr (-util) is not the only consumer of either the expat or the libxml2 component. Using an os distributor's synched and maintained flavor is always a better choice that whatever sources we might be able to distribute.
