Re: APR all in one lib?

["Ralf S. Engelschall" <rs...@engelschall.com>]

In article <19...@holly.calldei.com> 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
                                       rse@engelschall.com
                                       www.engelschall.com

Re: APR all in one lib?

[Chris Costello <ch...@calldei.com>]

On Mon, Nov 01, 1999, Ralf S. Engelschall wrote:
> 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.

   Building them by utilizing sub-Makefiles is trivial, and is
similar to the FreeBSD approach of building things.  Perhaps not
exactly the same, but very similar.  We have something like that
in just about every subdirectory.  ``make'' in src/usr.sbin/ will
build each program to be installed in /usr/sbin.

-- 
|Chris Costello <ch...@calldei.com>
|Objects are closer than they appear.
`------------------------------------