apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Greg Stein <gst...@lyra.org>
Subject Re: config tests (was: Re: cvs commit: httpd-2.0/support ...)
Date Fri, 22 Dec 2000 21:23:26 GMT
On Fri, Dec 22, 2000 at 01:16:51PM -0800, rbb@covalent.net wrote:
>...
> > "The feature". That is the problem with these tests. They're just looking
> > for a header, not a particular feature. I'm thinking that we want to have a
> > file describe the features it needs, then ask APR to get them for us.
> > 
> > For example:
> > 
> > #define APR_WANT_STDIO 1
> > #define APR_WANT_MEM_FUNCS 1
> > #define APR_WANT_STR_FUNCS 1
> > #include "apr_want.h"
> > 
> > Inside of apr_want.h, we test the various APR_WANT_* macros and fetch the
> > appropriate per-platform header for those features.
> > 
> > Note that apr_want.h wouldn't have the standard #ifdef _APR_WANT_H_ logic
> > around it, allowing it to be included multiple times. Since all it does is
> > include other headers (which have their own protection), this will be safe,
> > and it will allow the header to be included multiple times. At the end of
> > apr_want.h, we'd #undef all the APR_WANT_* macros so that people won't get a
> > redefinition if they go through another round of #define/#include apr_want.
> 
> I have a small thing I want to mention about this.  This doesn't remove
> the need for the APR_HAVE_*_H macros.  The thing is that apr_want.h still
> needs to use the namespace protected macros, because we can't expose the
> HAVE_*_H macros in a public header.

Agreed. I was about to say "and we can torch the APR_HAVE_*_H macros" until
I remembered that they'd be used within apr_want.h, which means they're
public. Thankfully, I recalled before saying it publicly and getting called
Mr Stoopid :-)

> Other than that one statement, I do really like this idea.

Coolness.

Cheers,
-g

-- 
Greg Stein, http://www.lyra.org/

Mime
View raw message