apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From r..@covalent.net
Subject Re: config tests (was: Re: cvs commit: httpd-2.0/support ...)
Date Fri, 22 Dec 2000 21:16:51 GMT

> I've been thinking about all these "APR_HAVE_FOO_H" tests. The app that is
> using APR(UTIL) is adding a series of includes like:
> #include <string.h>
> #endif
> #include <strings.h>
> #endif
> #include <unistd.h>
> #endif
> It does this because something like memset() can occur who-knows-where on
> all the different platforms out there. So it just includes the world in an
> attempt to find the feature.
> "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.

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


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

View raw message