apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Greg Stein <gst...@lyra.org>
Subject config tests (was: Re: cvs commit: httpd-2.0/support ...)
Date Fri, 22 Dec 2000 20:59:20 GMT
[ moved to dev@apr.apache.org ]

On Fri, Dec 22, 2000 at 12:24:14PM -0500, Jeff Trawick wrote:
> "William A. Rowe, Jr." <wrowe@lnd.com> writes:
> 
> > > So what if we have some autoconfiguration requirements in one of the
> > > support programs... It automatically goes in APR (-0)?  The support
> > > programs get their own configure script (-1)?
> > >
> > > Is APR now promising to figure out existence of all header files that
> > > any APR app might use and export as APR_HAVE_xyz_H?  What about
> > > functions?
> > 
> > I was thinking about that q as I did this patch.
> > 
> > If you want to avoid creating a config script for every consumer of this
> > library then, yes, I'd suggest any "Platform Dependent" situation would
> > be covered here.  This is why we create these for Apache, and any APR
> > consumer is duplicating that effort if we don't roll it into APR.
> 
> I don't think we can avoid a non-trivial consumer of APR from having
> its own config script.  What will happen (IMHO) is that we will
> happily add trivial stuff like testing for headers or functions or
> what-not but not feel comfortable adding other stuff like
> does-function-xyz-work unless it is meaningful for APR (or apps which
> core APR developers work on).
> 
> Another way of putting this is that we will be willing to do the stuff
> which is trivial for the app to do itself but we won't be willing to
> do much hard stuff.  (Who here likes to commit patches they don't
> understand or have no way to verify?)

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:

#if APR_HAVE_STRING_H
#include <string.h>
#endif
#if APR_HAVE_STRINGS_H
#include <strings.h>
#endif
#if APR_HAVE_UNISTD_H
#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 like it because it cleans up those "include everything to find memcmp()"
blocks. It is also very descriptive. Why is <strings.h> being included? Who
knows?

I *really* like it because when I write new code, I go and include
<string.h> for the functions. That's where they are on my Linux box. Well,
we just got a bunch of patches to also include <strings.h> because that's
where they are for Solaris. In other words, as a portable app developer, I
can't foresee all the different places some OS might put these, so I won't
write my code portabley. By using APR_WANT_*, I allow APR to get the right
thing done for me for any platform out there.

Thoughts?

Cheers,
-g

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

Mime
View raw message