You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@httpd.apache.org by Brian Havard <br...@kheldar.apana.org.au> on 1999/10/23 19:20:48 UTC

APR all in one lib?

To make things more managable I'd like to put APR into a single libapr.a
instead of libfile.a libnetwork.a etc. I've got a way of doing this ready to
commit. Does anyone NOT want to do that?

-- 
 ______________________________________________________________________________
 |  Brian Havard                 |  "He is not the messiah!                   |
 |  brianh@kheldar.apana.org.au  |  He's a very naughty boy!" - Life of Brian |
 ------------------------------------------------------------------------------


Re: APR all in one lib?

Posted by Chris Costello <ch...@calldei.com>.
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.

-- 
|Chris Costello <ch...@calldei.com>
|This message transmitted on 100% recycled electrons.
`----------------------------------------------------

Re: APR all in one lib?

Posted by Brian Havard <br...@kheldar.apana.org.au>.
On Sat, 23 Oct 1999 13:38:50 -0700 (PDT), Brian Behlendorf wrote:

>In what way does it make it significantly more manageable?  Just by having
>to link in one library vs. a couple?

Well, yeah. Having to add 9 -l switches is pain and there's probably more to
come. You also have to get certain APR libs in the right order because of
point below.



>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.

That'd be awkward. Some sections of APR use functions from other sections (EG
threadproc uses fileio) so separating them out wouldn't be possible and I
can't see why you'd want to. It's the linker's job to work out what library
code you actually need.

-- 
 ______________________________________________________________________________
 |  Brian Havard                 |  "He is not the messiah!                   |
 |  brianh@kheldar.apana.org.au  |  He's a very naughty boy!" - Life of Brian |
 ------------------------------------------------------------------------------


Re: APR all in one lib?

Posted by Ryan Bloom <rb...@raleigh.ibm.com>.
First of all, I'm back and trying to dig out from under my pile of e-mail.
The one big library is a good idea, and I was working on it when I left.
Good to see somebody else did it for me.  :)  The idea of not having to
build all of APR is important, and it will soon be possible to build APR
with configure options to not build some sections.  I think it is
currently possible to build APR without threads.  

I don't see this as a reason not to build everything into one big library.

Ryan

On Sat, 23 Oct 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.  =)
> 
> 	Brian
> 
> > ----- Original Message -----
> > From: Brian Havard <br...@kheldar.apana.org.au>
> > 
> > > To make things more managable I'd like to put APR into a single libapr.a
> > > instead of libfile.a libnetwork.a etc. I've got a way of doing this ready
> > to
> > > commit. Does anyone NOT want to do that?
> 
> 
> 

_______________________________________________________________________
Ryan Bloom		rbb@raleigh.ibm.com
4205 S Miami Blvd	
RTP, NC 27709		It's a beautiful sight to see good dancers 
			doing simple steps.  It's a painful sight to
			see beginners doing complicated patterns.	


Re: APR all in one lib?

Posted by Brian Behlendorf <br...@apache.org>.
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.  =)

	Brian

> ----- Original Message -----
> From: Brian Havard <br...@kheldar.apana.org.au>
> 
> > To make things more managable I'd like to put APR into a single libapr.a
> > instead of libfile.a libnetwork.a etc. I've got a way of doing this ready
> to
> > commit. Does anyone NOT want to do that?




Re: APR all in one lib?

Posted by David Reid <ab...@dial.pipex.com>.
Works for me...

+1
----- Original Message -----
From: Brian Havard <br...@kheldar.apana.org.au>
To: Apache Developers Mailing List <ne...@apache.org>
Sent: 23 October 1999 18:20
Subject: APR all in one lib?


> To make things more managable I'd like to put APR into a single libapr.a
> instead of libfile.a libnetwork.a etc. I've got a way of doing this ready
to
> commit. Does anyone NOT want to do that?
>
> --
>
____________________________________________________________________________
__
>  |  Brian Havard                 |  "He is not the messiah!
|
>  |  brianh@kheldar.apana.org.au  |  He's a very naughty boy!" - Life of
Brian |
>  -------------------------------------------------------------------------
-----
>


Re: APR all in one lib?

Posted by Chris Costello <ch...@calldei.com>.
On Sun, Oct 24, 1999, Brian Havard wrote:
> To make things more managable I'd like to put APR into a single libapr.a
> instead of libfile.a libnetwork.a etc. I've got a way of doing this ready to
> commit. Does anyone NOT want to do that?

   Though I'm hardly active on this list, I definitely agree!

+1

-- 
|Chris Costello <ch...@calldei.com>
|Programs: What software used to be, back when we knew how to write it.
`----------------------------------------------------------------------

Re: APR all in one lib?

Posted by Dean Gaudet <dg...@arctic.org>.
+1 (i can't imagine it any other way, -lthis -lthat -lthe -lother totally
sucks.)

On Sun, 24 Oct 1999, Brian Havard wrote:

> To make things more managable I'd like to put APR into a single libapr.a
> instead of libfile.a libnetwork.a etc. I've got a way of doing this ready to
> commit. Does anyone NOT want to do that?
> 
> -- 
>  ______________________________________________________________________________
>  |  Brian Havard                 |  "He is not the messiah!                   |
>  |  brianh@kheldar.apana.org.au  |  He's a very naughty boy!" - Life of Brian |
>  ------------------------------------------------------------------------------
> 
>