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 14:30:22 GMT
On Fri, 2 Mar 2001, Greg Stein wrote:

> On Thu, Mar 01, 2001 at 10:32:21PM -0800, rbb@covalent.net wrote:
> > On Thu, 1 Mar 2001, Roy T. Fielding wrote:
> > > On Thu, Mar 01, 2001 at 09:40:44PM -0800, rbb@covalent.net wrote:
> > > > We still need to APR namespace protection.  We tried to not namespace
> > > > protect things to begin with, and Apache and APR were conflicting
> > > > horribly.
> > >
> > > Because the method I described was not used.
>
> Goody for you, Oh Omniscient One. We are just poor souls who don't have your
> wisdom, so we fucked up the code.
>
> > Doesn't your model require that all APR applications define their
> > configuration macros the same way?  If an APR application is forced to do
> > all of their macros in a given way, then I am against this model.  If this
> > works regardless of how the app defines it macro's, then cool.
>
> If an application includes an APR header, and then includes its own header,
> then it will receive errors/warnings. Invariably, I always structure my
> headers (say) in Subversion like so:
>
> #include <some_apr_header.h>
> #include <another_apr_header.h>
>
> #include "public_svn_header.h"
> #include "another.h"
>
> #include "module_private_header.h"
>
>
> In the above scenario, my SVN headers would create duplicates. "So fix SVN."
> Okay, I happen to be able to do that. Now, let's add an Expat include in
> there. Ooops. Hey, I have privs to fix that, too. Now SVN includes Berkeley
> DB headers. Fuck.
>
> autoconf headers are just not meant to be mixed. If APR is intending to
> export the values, then they must be namespace protected. That implies that
> a plain old AC_CHECK_HEADER(foo.h) is not sufficient. We need to follow that
> up with setting a shell variable (fooh=0/1), then using that to def/undef or
> 0/1 an APR-namespace symbol.
>
> > > > Add to that, that we define our own macros that no other
> > > > package should have.
> > >
> > > That is a separate issue -- anything that is defined by an APR-specific
> > > macro should be name-protected.   I am only talking about the standard
> > > names that every autoconf package defines.
>
> We don't have a problem with the standard names. Those go into
> include/arch/unix/apr_private.h(.in). The issue is the generation of
> APR_HAVE_FOO_H in the public apr.h header. For those, we need logic beyond a
> simple AC_CHECK_HEADER().
>
> > What happens with a package that doesn't use autoconf?
>
> Presumbly, they wouldn't be using HAVE_STDIO_H, so a conflict won't occur.

True, but didn't Apache 1.3 have macros like HAVE_STDIO_H?  It is a
boundary condition, but I believe it is an issue.  That format for the
macros is pretty obvious.

<snip>

> I'm a big proponent of revamping the build system for Apache (more like
> APR(UTIL)), and a basic cleaning of its config system.

++1.  And I would add that a lot of the Apache autoconf stuff could just
go away and mvoe into APR.  I don't think Apache should be checking for
headers personally.

Ryan


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


Mime
View raw message