httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Ralf S. Engelschall" <>
Subject Re: APR all in one lib?
Date Mon, 01 Nov 1999 09:53:31 GMT

In article <> you wrote:
> On Sat, Oct 23, 1999, Brian Behlendorf wrote:

>> In what way does it make it significantly more manageable?  Just by having
>> to link in one library vs. a couple?
>> Here's why I ask - if one design goal of APR is to build a body of
>> portable code that could be used in other projects, it may be useful to be
>> able to partition functionality for situations where you need one type but
>> not another.  IIRC, that was one reason people elected not to use NSPR.
>> Though it's hard for me to come up with a credible example for a server
>> that would need abstracted network but not abstracted filesystem I/O, I
>> suppose.  =)
>    Thinking about it, it shouldn't be _extremely_ difficult to
> have an option to build one library or several libraries.  If I
> have some spare time around (which I usually do), I might see
> about playing with the Makefile(s) to do that, if anyone's really
> interested in keeping multiple libraries around.

If you build a all-in-one library out of sub-libraries as the global step in
the Makefile, this is trivial.  Just use the approach GNU shtool's arx command
does.  Just _merge_ the lib<sublib>.a's into a single libapr.a as the final
top-level step. Then you don't have to change anything in the sub-Makefiles.
Alternatively you can use OpenSSL's approach and just insert the objects
immediately into the top-level libapr.a from _within_ the sub-Makefiles.
That's medium-complex. The most complex (related to maintaining) approach is
to build the libapr.a inside the top-Makefile from all objects in the sub
areas. I wouldn't recommend you this.

                                       Ralf S. Engelschall

View raw message