apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From <...@covalent.net>
Subject Re: FreeBSD and gnu m4
Date Fri, 02 Mar 2001 05:40:44 GMT

We still need to APR namespace protection.  We tried to not namespace
protect things to begin with, and Apache and APR were conflicting
horribly.  Add to that, that we define our own macros that no other
package should have.

We have been down the road of exposing non-namespace protected macros
before, it didn't work then, and I don't believe it will work now.  Please
take a look at the archive from when we first put autoconf into APR,
and how it conflicted with Apache.


On Thu, 1 Mar 2001, Roy T. Fielding wrote:

> > Changing from "1" and "0" to def, undef wouldn't change anything at all.
> > The exact same logic is required, and the same general variables are
> > required.  The differences between the two are incredibly minor, because
> > we want to use namespace protected macros.
> If we changed to def/undef and we used the standard autoconf macros
> with the default behavior, then we don't need namespace protected symbols.
> Defining them as "0" or "1" doesn't allow us to use
>    #ifndef HAVE_UNISTD_H
>    #undef HAVE_UNISTD_H
>    #endif
> as the template for the generated file, which gets translated to
>    #ifndef HAVE_UNISTD_H
>    #define HAVE_UNISTD_H 1
>    #endif
> by configure if AC_CHECK_HEADERS(unistd.h) succeeds, which won't result
> in errors if the same symbol is defined by includes in other packages,
> which was the original justification for the APR_ prefix on those symbols.
> Of course, this means we'd have to use a template instead of autoheader,
> but that is how I prefer to set up autoconf in any case, since it also
> allows us to add documentation to the generated file.  Doing it this way
> has the nice side-effect of allowing the user to override a configure
> definition by simply doing a
>    env CFLAGS="-DHAVE_UNISTD_H=1" make
> I wasn't kidding when I said that our problems with autoconf
> are due to the way we are using it.
> ....Roy

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

View raw message