On 28.04.2012 09:05, Joe Schaefer wrote:
libapreq2 (which is the stuff currently sitting in trunk/server)
depends entirely on libapr and libaprutil- there are no httpd-specific
parts involved in it.
To me this suggests, it may be generally useful and thus should have a
life of its own -- outside of httpd source -- thus allowing other
projects to begin using it as a 3rd-party library, that can be listed as
a project's dependency.
Myself a porter of quite a few 3rd-party packages to my OS of choice
(FreeBSD), I have a deep resentment towards software projects, which
bundle multiple projects' code in their own sources. OpenOffice is the
worst offender by far in this regard, bundling not only all of /its own/
code together, but also including (and fully recompiling as part of the
build) the full sources of python, boost, libjpeg, expat, png, zlib,
epm, and a bunch of other projects... Had it not been for licensing
reasons, I'm pretty sure, they would've been bundling Java as well...
It is very rare (if ever), that such bundling is justified -- most of
the time it is done for reasons like:
* "We wish to provide complete build tree that can be built independently"
or
* "We don't want to support interactions with other versions of the
library, which you might have"
Neither reason is valid, in my not so humble opinion:
* The first reason leads to pessimizing well-managed computer systems
(using well-manageable OSes), where recent versions of all
dependencies are already independently available, for the benefit of
the poorly-managed ones.
* The second is completely superfluous, because no "support" is
promised neither implicitly nor explicitly anyway.
So, in the same opinion, not just libapreq (if it is, indeed, generally
useful), but also apr and aprutil ought to be available /only/ as
standalone packages and used as such during build by default.
Yours,
-mi
