On Fri, 2 Mar 2001, Greg Stein wrote: > On Thu, Mar 01, 2001 at 10:32:21PM -0800, [EMAIL PROTECTED] wrote: > > On Thu, 1 Mar 2001, Roy T. Fielding wrote: > > > On Thu, Mar 01, 2001 at 09:40:44PM -0800, [EMAIL PROTECTED] 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 [EMAIL PROTECTED] 406 29th St. San Francisco, CA 94131 -------------------------------------------------------------------------------
