You are viewing a plain text version of this content. The canonical link for it is here.

Posted to dev@httpd.apache.org by Jeff Trawick <tr...@bellsouth.net> on 2000/12/22 15:48:58 UTC

Re: cvs commit: httpd-2.0/support ab.c ab.dsp htdigest.c htdigest.dsp htpasswd.c htpasswd.dsp logresolve.c logresolve.dsp rotatelogs.c rotatelogs.dsp

wrowe@locus.apache.org writes:

> wrowe       00/12/21 13:00:48
> 
>   Modified:    support  ab.c ab.dsp htdigest.c htdigest.dsp htpasswd.c
>                         htpasswd.dsp logresolve.c logresolve.dsp
>                         rotatelogs.c rotatelogs.dsp
>   Log:
>     All the supports now build on APR (+APRUTIL), no reliance on
>   httpd.

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?

-- 
Jeff Trawick | trawickj@bellsouth.net | PGP public key at web site:
       http://www.geocities.com/SiliconValley/Park/9289/
             Born in Roswell... married an alien...

Re: config tests (was: Re: cvs commit: httpd-2.0/support ...)

Posted by Greg Stein <gs...@lyra.org>.

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/

Re: config tests (was: Re: cvs commit: httpd-2.0/support ...)

Posted by Greg Stein <gs...@lyra.org>.

On Fri, Dec 22, 2000 at 02:27:05PM -0800, rbb@covalent.net wrote:
> 
> > > I've been fighting OS/390 build problems for over a day because of the
> > > apr-util/.libs change.
> > 
> > If we reverted that change and just went against the .la again, would that
> > work for you? The use of .libs should never have happened.
> 
> -1.  The .libs thing works, reverting it just breaks every platform
> instead of just OS/390.  If you want to change to Sascha's mechanism fine,
> but you can't just back out the change.

Give me a break, Ryan. I *KNOW* that just removing that is insufficient. I'm
also testing the addition of --disable-shared to the subdir config, as I
mentioned earlier.

Sheesh.

-g

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

Re: config tests (was: Re: cvs commit: httpd-2.0/support ...)

Posted by Greg Stein <gs...@lyra.org>.

On Fri, Dec 22, 2000 at 02:27:05PM -0800, rbb@covalent.net wrote:
> 
> > > I've been fighting OS/390 build problems for over a day because of the
> > > apr-util/.libs change.
> > 
> > If we reverted that change and just went against the .la again, would that
> > work for you? The use of .libs should never have happened.
> 
> -1.  The .libs thing works, reverting it just breaks every platform
> instead of just OS/390.  If you want to change to Sascha's mechanism fine,
> but you can't just back out the change.

Give me a break, Ryan. I *KNOW* that just removing that is insufficient. I'm
also testing the addition of --disable-shared to the subdir config, as I
mentioned earlier.

Sheesh.

-g

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

Re: config tests (was: Re: cvs commit: httpd-2.0/support ...)

Posted by rb...@covalent.net.

> > > Have a merry christmas one and all, and Ryan try and spend some time with
> > > your lovely wife will you??!!
> > 
> > I'm gone to a b&b (with Kelly obviously) for the weekend, and the only
> > computer I'm bringing doesn't have a modem, so don't expect to hear from
> > me.  :-)
> 
> Um. Bringing a computer? It doesn't matter whether it has a modem or not. It
> shouldn't be there.

I know, but I don't have a choice.  I have a book and an article I need to
work on.  :-(

Ryan

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

Re: config tests (was: Re: cvs commit: httpd-2.0/support ...)

Posted by Greg Stein <gs...@lyra.org>.

On Fri, Dec 22, 2000 at 04:52:12PM -0800, rbb@covalent.net wrote:
> 
> > The "manual intervention" is to add "../apr/libapr.a" to the build line to
> > get all the symbols resolved for BeOS.  Doing this gives libtool a pause and
> > it only then builds the libaprutil.a library.  Of course when we come to the
> > final link stage and we pass libaprutil.la it then doesn't bother adding
> > anything to the linka nd so it fails with a good number of unresolved
> > symbols and I have to then add the library manually to get it completed...
> > :(
> 
> Shouldn't the change to .libs/libaprutil.a have taken care of this for
> you?

He is referring to the link step of libaprutil itself.

It shouldn't be a problem to add @APR_SOURCE_DIR@/libapr.la to the link when
we get APR libtool'd. Until that point, we can add -L@APR_SOURCE_DIR@ -lapr
to the link line. That should be an acceptable patch until APR is libtool'd.

> > Have a merry christmas one and all, and Ryan try and spend some time with
> > your lovely wife will you??!!
> 
> I'm gone to a b&b (with Kelly obviously) for the weekend, and the only
> computer I'm bringing doesn't have a modem, so don't expect to hear from
> me.  :-)

Um. Bringing a computer? It doesn't matter whether it has a modem or not. It
shouldn't be there.

;-)

Happy holidays,
-g

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

Re: config tests (was: Re: cvs commit: httpd-2.0/support ...)

Posted by Greg Stein <gs...@lyra.org>.

On Sat, Dec 23, 2000 at 12:38:28AM -0000, David Reid wrote:
>...
> > That is also simply fixed by passing --disable-shared from the top-level
> > configure. Although, we should be able to work with shared libraries, so we
> > need to find out what his "human intervention" really means. In other words,
> > --disable-shared simply hides other problems that need to be fixed. By the
> > time that we release, we should not be using --disable-shared.
> 
> The "manual intervention" is to add "../apr/libapr.a" to the build line to
> get all the symbols resolved for BeOS.  Doing this gives libtool a pause and
> it only then builds the libaprutil.a library.  Of course when we come to the
> final link stage and we pass libaprutil.la it then doesn't bother adding
> anything to the linka nd so it fails with a good number of unresolved
> symbols and I have to then add the library manually to get it completed...

Hmm. I see. It is possible that it is failing the link of the shared lib.
Thus, if you disable the shared lib build, then we'd be okay for now.

We will want to put it back to dynamic library building at some point,
however.

> I'll try a build with --disbale-shared but as apache 2.0 is the first

It is in the top-level configure now. Just update from CVS and try it.

>...
> How about having a define in the process that we can set with flags to pass
> to apr-utils build?  Then we can set --disable-shared for just apr-util and
> solve the problem?  perhaps add it to apr's hints.m4?  Just a thought.
> Don't know if it would work.

It's in there now. In the future, we could always add it only for BeOS, but
I'd think that if BeOS is just never going to get it right, then we do that
within aprutil itself. There may be some things that we can do to/with
libtool itself to make this smoother.

In any case, we'd want to localize the change within aprutil. If Apache
can't deal with a dynamic library of aprutil, there is no reason to expect
that others will.

Cheers,
-g

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

Re: config tests (was: Re: cvs commit: httpd-2.0/support ...)

Posted by rb...@covalent.net.

> The "manual intervention" is to add "../apr/libapr.a" to the build line to
> get all the symbols resolved for BeOS.  Doing this gives libtool a pause and
> it only then builds the libaprutil.a library.  Of course when we come to the
> final link stage and we pass libaprutil.la it then doesn't bother adding
> anything to the linka nd so it fails with a good number of unresolved
> symbols and I have to then add the library manually to get it completed...
> :(

Shouldn't the change to .libs/libaprutil.a have taken care of this for
you?

> Have a merry christmas one and all, and Ryan try and spend some time with
> your lovely wife will you??!!

I'm gone to a b&b (with Kelly obviously) for the weekend, and the only
computer I'm bringing doesn't have a modem, so don't expect to hear from
me.  :-)

Ryan

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

Re: config tests (was: Re: cvs commit: httpd-2.0/support ...)

Posted by David Reid <dr...@jetnet.co.uk>.

> > Love the concept...don't like the timing. Can it wait until after the
> > beta?

Yeah, the concept is a good one...

+1

> > I've been fighting OS/390 build problems for over a day because of the
> > apr-util/.libs change.

Know the feeling...

> > Sounds like it's giving David Reed some grief also.

sp x 50!

> That is also simply fixed by passing --disable-shared from the top-level
> configure. Although, we should be able to work with shared libraries, so
we
> need to find out what his "human intervention" really means. In other
words,
> --disable-shared simply hides other problems that need to be fixed. By the
> time that we release, we should not be using --disable-shared.

The "manual intervention" is to add "../apr/libapr.a" to the build line to
get all the symbols resolved for BeOS.  Doing this gives libtool a pause and
it only then builds the libaprutil.a library.  Of course when we come to the
final link stage and we pass libaprutil.la it then doesn't bother adding
anything to the linka nd so it fails with a good number of unresolved
symbols and I have to then add the library manually to get it completed...
:(

I'll try a build with --disbale-shared but as apache 2.0 is the first
version of apache on BeOS that supports dynamic libraries I don't really
want to say "sure we have the support but because of the build system and
BeOS's linker we have to build statically".  Not cool.

How about having a define in the process that we can set with flags to pass
to apr-utils build?  Then we can set --disable-shared for just apr-util and
solve the problem?  perhaps add it to apr's hints.m4?  Just a thought.
Don't know if it would work.

Have a merry christmas one and all, and Ryan try and spend some time with
your lovely wife will you??!!

:))

david

Re: config tests (was: Re: cvs commit: httpd-2.0/support ...)

Posted by greg <gr...@raleigh.ibm.com>.

Greg Stein wrote:
> 
> > Love the concept...don't like the timing. Can it wait until after the
> > beta?
> 
> I believe the beta is indefinitely delayed. It'll be at least a week.
> 
> That said: I'm out of town Saturday thru Thursday, so I wouldn't be doing
> this for a while anyways.
> 
> > I've been fighting OS/390 build problems for over a day because of the
> > apr-util/.libs change.
> 
> If we reverted that change and just went against the .la again, would that
> work for you? The use of .libs should never have happened.
> 

We updated the OS/390 libtool to deal with .libs, so now we can build
fine either way. Let's just do the Right Thing here (whatever that is).  

My point is that the code base seems to be less than beta quality at
present, and this sounds like a fairly big change.  I'm going to start
debugging the OS/390 static page problems ASAP.  What about
FreeBSD...any progress there?

Greg

Re: config tests (was: Re: cvs commit: httpd-2.0/support ...)

Posted by rb...@covalent.net.

> > I've been fighting OS/390 build problems for over a day because of the
> > apr-util/.libs change.
> 
> If we reverted that change and just went against the .la again, would that
> work for you? The use of .libs should never have happened.

-1.  The .libs thing works, reverting it just breaks every platform
instead of just OS/390.  If you want to change to Sascha's mechanism fine,
but you can't just back out the change.

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

Re: config tests (was: Re: cvs commit: httpd-2.0/support ...)

Posted by rb...@covalent.net.

> > I've been fighting OS/390 build problems for over a day because of the
> > apr-util/.libs change.
> 
> If we reverted that change and just went against the .la again, would that
> work for you? The use of .libs should never have happened.

-1.  The .libs thing works, reverting it just breaks every platform
instead of just OS/390.  If you want to change to Sascha's mechanism fine,
but you can't just back out the change.

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

Re: config tests

Posted by Greg Stein <gs...@lyra.org>.

On Thu, Dec 28, 2000 at 06:27:43AM -0800, rbb@covalent.net wrote:
> 
> > My suggestion though... let's follow the ansi/posix/unix spec and simply
> > #define WANT_APR_STDIO_H before including apr... e.g. we know what the
> > offical stdio.h should have, so if it's a matter of including stdio plus
> > stdlib plus conio on win32, then that's what the win32 port does.
> 
> The problem is that it isn't just Win32.  Different Unixes put different
> functions in different header files.

Exactly. And saying "WANT_APR_STDIO_H" is completely the opposite direction
of what the apr_want.h stuff is trying to do. We want *FEATURE* inclusion,
not something to say "include stdio.h for me, please". Bah. The caller can
just do that themselves.

The program enumerates the *features*, then apr_want.h gets those features
from wherever they are.

Yes, we'll probably have one called APR_WANT_STDIO meaning the "standard
I/O" features. If the platform doesn't have stdio.h, then we can punt with a
#error (cuz we certainly can't continue without the FILE type defined).

If using #error isn't sufficient, and bits of (needed) stdio can be found in
other headers, then we may need to refine the WANT symbols. e.g. WANT_PRINTF
or WANT_FILE_TYPE or whatever; then we go find those specific features.

Whatever... but APR_WANT_STDIO_H is the wrong direction.

Cheers,
-g

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

RE: config tests (was: Re: cvs commit: httpd-2.0/support ...)

Posted by "William A. Rowe, Jr." <wr...@rowe-clan.net>.

> From: rbb@covalent.net [mailto:rbb@covalent.net]
> Sent: Thursday, December 28, 2000 8:28 AM
> 
> > My suggestion though... let's follow the ansi/posix/unix spec and simply
> > #define WANT_APR_STDIO_H before including apr... e.g. we know what the
> > offical stdio.h should have, so if it's a matter of including stdio plus
> > stdlib plus conio on win32, then that's what the win32 port does.
> 
> The problem is that it isn't just Win32.  Different Unixes 
> put different functions in different header files.

Reread with s/win32 port/yourplatform port/

Yes, of course.  I just don't want a bunch of individual APR_WANT_PRINTF,
nor do I want to have us invent a bunch of arbitrary groupings.  Ansi spec
already went to the trouble of grouping them, and while perhaps no 
platform is 100% ansi, at least it's a place to start.

Bill

RE: config tests (was: Re: cvs commit: httpd-2.0/support ...)

Posted by rb...@covalent.net.

> My suggestion though... let's follow the ansi/posix/unix spec and simply
> #define WANT_APR_STDIO_H before including apr... e.g. we know what the
> offical stdio.h should have, so if it's a matter of including stdio plus
> stdlib plus conio on win32, then that's what the win32 port does.

The problem is that it isn't just Win32.  Different Unixes put different
functions in different header files.

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

RE: config tests (was: Re: cvs commit: httpd-2.0/support ...)

Posted by "William A. Rowe, Jr." <wr...@rowe-clan.net>.

This is a great idea :-)

My suggestion though... let's follow the ansi/posix/unix spec and simply
#define WANT_APR_STDIO_H before including apr... e.g. we know what the
offical stdio.h should have, so if it's a matter of including stdio plus
stdlib plus conio on win32, then that's what the win32 port does.

Refer to everything by some -very- consistent id (the spec is best) and
we should have a mission + a reasonable chance of success.

One thing that is guarenteed to screw us up, however, is the sequence of
defines and include "apr.h" ... but I know you already have a great 
solution thought up :-)

Bill

> -----Original Message-----
> From: Greg Stein [mailto:gstein@lyra.org]
> Sent: Friday, December 22, 2000 4:21 PM
> To: new-httpd@apache.org; dev@apr.apache.org
> Subject: Re: config tests (was: Re: cvs commit: httpd-2.0/support ...)
> 
> 
> On Fri, Dec 22, 2000 at 04:57:10PM -0500, greg wrote:
> > Greg Stein wrote:
> > > 
> > >                   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"
> > > 
> > 
> > Love the concept...don't like the timing. Can it wait until 
> after the
> > beta? 
> 
> I believe the beta is indefinitely delayed. It'll be at least a week.
> 
> That said: I'm out of town Saturday thru Thursday, so I 
> wouldn't be doing
> this for a while anyways.
> 
> > I've been fighting OS/390 build problems for over a day 
> because of the
> > apr-util/.libs change.
> 
> If we reverted that change and just went against the .la 
> again, would that
> work for you? The use of .libs should never have happened.
> 
> > Sounds like it's giving David Reed some grief also.
> 
> That is also simply fixed by passing --disable-shared from 
> the top-level
> configure. Although, we should be able to work with shared 
> libraries, so we
> need to find out what his "human intervention" really means. 
> In other words,
> --disable-shared simply hides other problems that need to be 
> fixed. By the
> time that we release, we should not be using --disable-shared.
> 
> Cheers,
> -g
> 
> -- 
> Greg Stein, http://www.lyra.org/
>

Re: config tests (was: Re: cvs commit: httpd-2.0/support ...)

Posted by Greg Stein <gs...@lyra.org>.

On Fri, Dec 22, 2000 at 04:57:10PM -0500, greg wrote:
> Greg Stein wrote:
> > 
> >                   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"
> > 
> 
> Love the concept...don't like the timing. Can it wait until after the
> beta? 

I believe the beta is indefinitely delayed. It'll be at least a week.

That said: I'm out of town Saturday thru Thursday, so I wouldn't be doing
this for a while anyways.

> I've been fighting OS/390 build problems for over a day because of the
> apr-util/.libs change.

If we reverted that change and just went against the .la again, would that
work for you? The use of .libs should never have happened.

> Sounds like it's giving David Reed some grief also.

That is also simply fixed by passing --disable-shared from the top-level
configure. Although, we should be able to work with shared libraries, so we
need to find out what his "human intervention" really means. In other words,
--disable-shared simply hides other problems that need to be fixed. By the
time that we release, we should not be using --disable-shared.

Cheers,
-g

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

Re: config tests (was: Re: cvs commit: httpd-2.0/support ...)

Posted by Greg Stein <gs...@lyra.org>.

On Fri, Dec 22, 2000 at 04:57:10PM -0500, greg wrote:
> Greg Stein wrote:
> > 
> >                   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"
> > 
> 
> Love the concept...don't like the timing. Can it wait until after the
> beta? 

I believe the beta is indefinitely delayed. It'll be at least a week.

That said: I'm out of town Saturday thru Thursday, so I wouldn't be doing
this for a while anyways.

> I've been fighting OS/390 build problems for over a day because of the
> apr-util/.libs change.

If we reverted that change and just went against the .la again, would that
work for you? The use of .libs should never have happened.

> Sounds like it's giving David Reed some grief also.

That is also simply fixed by passing --disable-shared from the top-level
configure. Although, we should be able to work with shared libraries, so we
need to find out what his "human intervention" really means. In other words,
--disable-shared simply hides other problems that need to be fixed. By the
time that we release, we should not be using --disable-shared.

Cheers,
-g

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

Re: config tests (was: Re: cvs commit: httpd-2.0/support ...)

Posted by rb...@covalent.net.

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


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

config tests (was: Re: cvs commit: httpd-2.0/support ...)

Posted by Greg Stein <gs...@lyra.org>.

[ moved to dev@apr.apache.org ]

On Fri, Dec 22, 2000 at 12:24:14PM -0500, Jeff Trawick wrote:
> "William A. Rowe, Jr." <wr...@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/