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. >... > > As I mentioned when I started the build blues thread, I read the archives > > first. Most of the decisions back then were made because APR had to be > > integrated with a non-configure-based httpd. I have the benefit of > > That's not true. Most of the problems weren't even discovered until we > integrated APR into a configure-based Apache. Exactly. Mix one autoconf'd guy with another, and you're in for trouble. > > hindsight and a holistic view of the build system, so it shouldn't be > > too surprising that I can think of a solution that may not have been > > possible back then. And you're saying that we don't have that either? That only you possess that knowledge? That isn't fair, Roy. The current spate of problems was due to some M4 coding that I was doing to simplify and optimize our configuration. Unfortunately, despite M4's age, it appears to be rather non-portable and prone to flakiness. We backed off a bit, but we're still in a very good and stable spot. No more deep magic, and it should all work quite fine. We don't do anything beyond normal autoconf setups. > I hope you have found new ideas, but the current APR configuration system > is much more autoconf-like than the Apache one, and most of the problems > haven't been with the APR configure system. Exactly. This recent spate was M4. My fault. Our autoconf system has been working quite well. > > The reason I bring it up right now is because every step we have taken away > > from a standard autoconf setup has resulted in significant problems on > > one platform or another, leading to another step away and more problems, > > ad nauseum. Some steps, like not using the standard generating mechanism > > for the Makefile files, have benefits that outweigh the pain. Others do > > not. > > I look at the APR configuration system, and I see a system that is very > close to what autoconf expects. Exactly. It is much more complex than many because it touches "all" of an operating system's features. Many apps just don't have that kind of breadth, so their configure scripts are quite short (look at Expat). > Apache, on the other hand is completely > non-autoconf. However, this model is not completely broken, and it is > what PHP uses, which is why it was originally chosen. I am 100% for > fixing this mess, but I am concerned by the number of times that this > issue has been raised, and never resolved. When the Apache stuff was first put in, based on the PHP stuff, I wasn't paying much attention to it. It seemed to work, so that was fine. But over the past year or so (or however long it has been), I've had to deal with it more and more. Gads. It definitely does things "different" in an attempt to do things faster. The whole APACHE_SUBST and APACHE_FAST_OUTPUT and APACHE_OUTPUT was done to avoid variable substitution. Yet I find that to be a poor tradeoff (I could go either way with this; sounds like Roy likes it; with a general cleaning of the Apache autoconf, it might be more obvious and useful to use). There was also a lot of crud remaining in Apache simply because it was autoconf'd in a big whack before we settled on what should be done by APR and what should be done by Apache. And the build stuff is just messy (quick: what is the difference between library.mk ltlib.mk program.mk and special.mk?) And the whole build2.mk thang. I'm a big proponent of revamping the build system for Apache (more like APR(UTIL)), and a basic cleaning of its config system. Cheers, -g -- Greg Stein, http://www.lyra.org/
