httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Paul Sutton <>
Subject Re: ap_ prefix to funcs (was: Re: patches from "Paul B. Henson")
Date Wed, 03 Sep 1997 09:43:30 GMT
On Tue, 2 Sep 1997, Dean Gaudet wrote:
> Given that these other systems expect to be linked against apache ... I'm
> not sure why they have this problem.  Rasmus? 
> But it would be cleared up a whole bunch I think if we created a libap.a
> which contained all of our support functions that exist for OS
> compatibility and whatnot.  Then php could include -lap while testing for
> functions it needs. 

Yeah, sounds like a good idea. One question that I've been pondering
recently is how much the OS abstractions should know about Apache. Ideally
they shouldn't have to know anything about Apache at all, but *many* of
the things that would be nice to abstract (such as the recent
os_canonical_filename) need to do memory allocation, so they need to know
about pools. 

So should the functions and headers is os/* know about pools (i.e. include
"alloc.h") or not? If they do know about pools it makes abstraction much
easier because the functions (such as os_canonical_filename) and their
prototypes can be stuck into os.c/os.h as necessary. If the os files do
not know about pools then everything has to be done via defined constants
then the OS specific code stuck into a file in main, which is not so

On the other hand, the os abstractions may in the future be used for other
support programs (e.g. htpasswd) which do not need to know about pools. 

I'm leaning towards letting os/* know about pools. Then we can move all
the OS-specific stuff out of conf.h into os/*/os.h, put #include "os.h"
into conf.h, and then actually abstract things.

(Incidently os_canonical_filename currently *does* work despite being in
os/win32, but only because it is compiled as part of ApacheCore. It won't
work if a similar (and it is necessary) os_canonical_filename is added to


View raw message