apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "William A. Rowe Jr." <wr...@rowe-clan.net>
Subject Re: Proposal: splitting APR and former apr-util libraries
Date Fri, 03 Jun 2011 05:25:47 GMT
On 6/3/2011 12:05 AM, Greg Stein wrote:
> On Thu, Jun 2, 2011 at 07:51, Graham Leggett <minfrin@sharp.fm> wrote:
>> It seems what we're working towards is combining apr and apr-util, removing
>> most of the stuff that was in apr-util, ending up pretty much back with apr,
>> which leads me to ask why we ever bothered combining the two in the first
>> place.
> Dunno. Go do the research in the svn logs. Somebody did the commit.
> Look for the discussion around then, or ask that committer.

None of the merging of apr and apr-util would have even been
considered, until we had factored out all of the library dependencies
into sub-components of apr which *need not be loaded*.  Even apr 1.x
core itself had too many dependencies which weren't necessary for
each and every consumer.

So dbd, dbm, even ldap were no longer triggered by 'linking to apr'.
Totally agreed with Greg in that older discussion that this was wrong.

Of course, ldap triggers the need to rebind the consumer application
to the same ldap library as apr was built against, so it violated all
of the separation principals.

But before we ship 2.0, it will be good to also lose the dependency
on always loading iconv, and expat/libxml2, and any other remnants
of being both a generalization library for the os/kernel, and also
a generalization library for most commonly required function libraries.

View raw message