Flexability for APR

[David Reid <ab...@dial.pipex.com>]

Attached are 2 small patches that alter the way that APR is configured.

The aim is to allow for a platform to define it's OSDIR but then not have
one present for a particular module.  The first example of this will
probably be the removal of the file_io/beos and time/beos directories.  At
present these both simply have a makefile.in that points at the Unix
directory, which seems like a lame way of doing this.

The patch defines a DEFAULT_OSDIR which is used if no OSDIR is present.
Essentially it loops through the modules to be included and if there is an
OSDIR uses that, if not it uses the DEFAULT_OSDIR.  The aim is to allow for
maximum common code use, which should lead to fewer maintenance headaches.

Why?  If you look at various platforms they are able to use the majority of
the Unix code but need to define their own routines for one or two modules
as they are totally different.  They should be able to simply add their own
directories for those modules that require them.  These patches enable that
with a minimum of fuss.

Again, I'm sure that people will jump in with problems and suggestions, but
that's OK as I'm learning more about this stuff as I go and welcome any and
all feedback.

david

Re: Flexability for APR

[Ryan Bloom <rb...@raleigh.ibm.com>]

Reading this again, I should probably mention that this is just the part
that makes the VPATH work possible.  All it really is doing, is adding
some MUCH needed flexibility, and allowing common code to be truly common
given.  The patch I am advocating committing puts the common-ness at the
directory level.  The next patch, would allow separate files within each
directory to be declared as common code.

I hope my original message didn't sound too strong, it was really just a
VERY big +1, but it didn't sound that way after I read it a second time.
:->

Ryan

On Fri, 8 Oct 1999, Ryan Bloom wrote:

> 
> 
> David,
> 
> Let's go ahead an commit this ASAP.  I'm going to build on top of this for
> my modularization work, and I would like to start to work on that tomorrow
> sometime.
> 
> Ryan
> 
> _______________________________________________________________________
> 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.	
> 

_______________________________________________________________________
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: Flexability for APR

[Ryan Bloom <rb...@raleigh.ibm.com>]

David,

Let's go ahead an commit this ASAP.  I'm going to build on top of this for
my modularization work, and I would like to start to work on that tomorrow
sometime.

Ryan

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