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 06:32:21 GMT
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.

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.

> > 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.

What happens with a package that doesn't use autoconf?

> > 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.
>
> 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.

> 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.

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.

> 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.  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.

Ryan

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



Mime
View raw message