Joe Orton wrote:
> On Tue, Mar 24, 2009 at 05:43:52PM +0100, William Rowe wrote:
>
>> Mladen Turk wrote:
>>
>>> Joe Orton wrote:
>>>
>>>> On the topic of how to split up APR into multiple libraries, I had a
>>>> look through the current directories, and a first cut at how I'd
>>>> propose to split the code up would be:
>>>>
> ...
>
>>> What's the technical reason for that?
>>> With the merging of apr and apr-util I was hoping
>>> we would have to care only on a single library
>>> and now there will be dozen of them. Scary.
>>>
>> Yes - I think this is a little overboard, but must be balanced
>> by the size of the code.
>>
>
> Right - but the primary motivation is as Ruediger says, to isolate
> dependencies, not to split by size.
>
> w.r.t. size, I did this for the apr-trunk, which I think is a reasonable
> measure of code size across directories - for information...
>
> $ for f in *; do \
> find $f -name \*.o | xargs ar cru ${f}.a && strip -g ${f}.a; \
> done
> $ ls -1sk *.a | sort -n | tail -20
> 16 uri.a
> 20 hooks.a
> 28 xml.a
> 40 memory.a
> 44 random.a
> 44 tables.a
> 48 ldap.a
> 56 crypto.a
> 56 memcache.a
> 56 misc.a
> 56 poll.a
> 60 threadproc.a
> 64 dbd.a
> 68 locks.a
> 72 dbm.a
> 76 strings.a
> 80 network_io.a
> 104 buckets.a
> 104 util-misc.a
> 120 file_io.a
>
So ... are you proposing we modularize APR to a zillion libs so that one
can chose bits and pieces for, e.g., and embedded app? I really don't
think that'll work out that well.
I don't mind if we build these separate (static) libs as an intermediate
step -- that would enable some really picky user to take just the bits
she needs -- as long the real build result is one libapr.(a|so) plus a
bunch of DSOs with third-party dependencies and/or variant implementations.
-- Brane
