apr/include/arch

["William A. Rowe, Jr." <wr...@rowe-clan.net>]

Ryan,

  is there a reason we choose to include "plat/foo.h" rather than
set the include path to include/arch/myplat, include/arch/unix, include
(in that order)?

Bill

RE: apr/include/arch

["William A. Rowe, Jr." <wr...@rowe-clan.net>]

> From: rbb@covalent.net [mailto:rbb@covalent.net]
> Sent: Thursday, November 09, 2000 11:47 AM
> 
> On Thu, 9 Nov 2000, William A. Rowe, Jr. wrote:
> 
> > Ryan,
> > 
> >   is there a reason we choose to include "plat/foo.h" rather than
> > set the include path to include/arch/myplat, include/arch/unix, include
> > (in that order)?
> 
> The only reason is that this ties all code re-use to the unix
> platform.  That may be OK, or it may not.  I personally think it makes
> sense for the C file to specify which header file it requires, because
> that allows one C file to refer to different platforms for different
> headers.  However, it also restricts that the C file knows which 
> platform it wants.  This is a trade-off.  I may have made the wrong 
> choice.  I really don't have a good answer, because I think it is 
> 6-one-half-dozen of the other here.

My patch to apr includes: 

  ./include ./include/arch ./include/arch/win32 ./include/arch/unix

so all is well, at least for today.

> One way the C file decides which header to use.  The other 
> the Makefiles (or .dsps) decide.  I haven't got a clue which 
> is easier to maintain.  :-)

Really, I'd rather see namespace protection (include "aprarch/foo.h" 
and include "apr/apr_foo.h") rather than these platform names.  
I'll grant that they are nearly equal tradeoffs, but the way we do it
now means that a simple patch and creation of a special case .h file
is a source change to half a dozen (plus) c files.  That isn't good.
As we chatted about ... I agree that the hybrid as400+mainframe or the
win32+os2 cases are a pain in this structure.  That's why I propose we
create arch/bigiron/ or arc/msibm for the hybrids, choosing decent
names that tag them as a common ancestor.

Re: apr/include/arch

[rb...@covalent.net]

On Thu, 9 Nov 2000, William A. Rowe, Jr. wrote:

> Ryan,
> 
>   is there a reason we choose to include "plat/foo.h" rather than
> set the include path to include/arch/myplat, include/arch/unix, include
> (in that order)?

The only reason is that this ties all code re-use to the unix
platform.  That may be OK, or it may not.  I personally think it makes
sense for the C file to specify which header file it requires, because
that allows one C file to refer to different platforms for different
headers.  However, it also restricts that the C file knows which platform
it wants.  This is a trade-off.  I may have made the wrong choice.  I
really don't have a good answer, because I think it is 6-one-half-dozen of
the other here.

One way the C file decides which header to use.  The other the Makefiles
(or .dsps) decide.  I haven't got a clue which is easier to
maintain.  :-)

Ryan

_______________________________________________________________________________
Ryan Bloom                        	rbb@apache.org
406 29th St.
San Francisco, CA 94131
-------------------------------------------------------------------------------