Re: ap_ prefix to funcs (was: Re: patches from "Paul B. Henson")

[Dean Gaudet <dg...@arctic.org>]

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. 

Dean

On Wed, 27 Aug 1997, Martin Kraemer wrote:

> Doug MacEachern wrote,...
> > ... I suppose
> > we should prefix them with ap_ instead of apache_ to be consistent.
> > The patches look fine to me, +1.  If the other changes look okay to
> > the os gurus, I'll take care of s/apache_/ap_/g and the commit.
> 
> On a related topic: should the replacement routines which are included
> via NEED_<func> defines (main/util.c) be prefixed as well? I think of
> something like
> conf.h:
> 
>     #ifdef NEED_STRCASECMP
>     extern int ap_strcasecmp(...);
>     #define  strcasecmp(str1,str2)  ap_strcasecmp(str1,str2)
>     #endif
> 
> in util.c:
>     int
>     ap_strcasecmp(...
> 
> This would reduce the risk of a clash with other "replacement" functions
> of the same name (like, e.g., in libphp.a).
> 
>     Martin
> -- 
> | S I E M E N S |  <Ma...@mch.sni.de>  |      Siemens Nixdorf
> | ------------- |   Voice: +49-89-636-46021     |  Informationssysteme AG
> | N I X D O R F |   FAX:   +49-89-636-44994     |   81730 Munich, Germany
> ~~~~~~~~~~~~~~~~My opinions only, of course; pgp key available on request
> 

Re: ap_ prefix to funcs (was: Re: patches from "Paul B. Henson")

[Dean Gaudet <dg...@arctic.org>]

Yeah pools can/should be abstracted.  The application linking against
libap using pools should provide block_alarms()/unblock_alarms().
Otherwise a stub in libap should provide dummy versions.

Dean

On Wed, 3 Sep 1997, Paul Sutton wrote:

> 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
> neat. 
> 
> 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. 
> Umm. 
> 
> 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
> os/emx/os.c).
> 
> //pcs
> 
> 
> 

Re: ap_ prefix to funcs (was: Re: patches from "Paul B. Henson")

[Paul Sutton <pa...@ukweb.com>]

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

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

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
os/emx/os.c).

//pcs