httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From r..@covalent.net
Subject Re: Deja vu
Date Fri, 29 Dec 2000 19:35:44 GMT

Okay, I will try to explain why we do what we do, and how to best solve
this problem.  :-)  If anything doesn't make sense after this, please let
me know.

We have two sets of definitions that we need to deal with, those that are
private to APR and those that are exported from APR.  Autoconf does not
allow us to specify a prefix for all macros that are defined, so we have
to do this ourselves.  This is why we have both apr.h and
apr_private.h.  apr_private.h is a header that can NEVER be included from
any .c file outside of APR.  If we do, then we will export a bunch of
macros that have the form HAVE_*, which will conflict with any other
autoconf project, such as Apache or PHP.

So, when you see something like:

> AC_CHECK_FUNCS(strcasecmp stricmp setsid nl_langinfo)

We are just using autoconf's tests to test for functions that APR needs to
know about.  This will create the macros HAVE_STRCASECMP, HAVE_STRICMP,
etc.

When you see somthing like:

> AC_CHECK_FUNCS(stricmp, have_stricmp="1", have_stricmp="0")

What we are saying is, check for stricmp, and if we have it then set a
variable have_stricmnp appropriately.  The have_stricmp variable is later
substituted into apr.h.in so that we can define APR_HAS_STRICMP.  This is
a macro that non-apr C files can use to test for have_stricmp.  It is also
a macro that the public apr header files can check.

> so what's the score there, then? And I notice things like:
> 
> AC_CHECK_FUNCS(fork, [ fork="1" ], [ fork="0" ])
> 
> which end up defining HAS_FORK instead of HAVE_FORK. What's that all
> about?

The other thing we want to do is be able to create feature macros, such as
APR_HAS_FORK, so that programs can check for the existance of some
functions, without having to make their own checks.


The general rule is to only create an APR_HAS_* macro for a feature that
is really necessary outside of APR.  In this case, getpwnam_r is only
used inside of APR, and so we just want to use
AC_CHECKFUNCS(getpwnam_r) inside of configure.in, and then in homedir.c,
change the test exactly as you described.  Leave apr.h.in alone
please.  We should also probably output a warning message if we can't find
getpwnam_r and we have threads enabled.

> Index: srclib/apr/user/unix/homedir.c
> ===================================================================
> RCS file: /home/cvs/apr/user/unix/homedir.c,v
> retrieving revision 1.1
> diff -u -r1.1 homedir.c
> --- srclib/apr/user/unix/homedir.c      2000/11/13 03:18:18     1.1
> +++ srclib/apr/user/unix/homedir.c      2000/12/29 19:01:03
> @@ -71,7 +71,7 @@
>      char pwbuf[512];
>  #endif
>  
> -#if APR_HAS_THREADS && defined(_POSIX_THREAD_SAFE_FUNCTIONS)
> +#if APR_HAS_THREADS && defined(_POSIX_THREAD_SAFE_FUNCTIONS) &&
> HAVE_GETPWNAM_R
>      if (!getpwnam_r(userid, &pwd, pwbuf, sizeof(pwbuf), &pw)) {
>  #else
>      if ((pw = getpwnam(userid)) != NULL) {
> 
> Should I? Shouldn't I? (OK, possibly the last one should become simply
> "#if HAVE_GETPWNAM_R").

Hopefully my answer above should answer those questions.  I would suggest
using the full test that you have in the patch.  Just changing this to #if
HAVE_GETPWNAM_R would ignore the test for threads.  The problem with that,
is that some platforms get better performance if we don't use the _r
functions when the program isn't threaded.

Does that clear things up?  I believe, although I could be wrong, that a
lot of this is covered in the APRDesign doc.  I really need to get a few
days to pull that doc apart, and elaborate on a lot of stuff in there, and
get the web page updated, but that won't happen until we hit a beta
release.

Ryan 

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


Mime
View raw message