httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "William A. Rowe, Jr." <wr...@rowe-clan.net>
Subject RE: apr/include/arch
Date Thu, 09 Nov 2000 19:29:59 GMT
> 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.



Mime
View raw message