You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@apr.apache.org by "Roy T. Fielding" <fi...@ebuilt.com> on 2001/03/02 03:32:02 UTC
Re: FreeBSD and gnu m4
Correct me if I am wrong, but all these changes and problems are
simply to reduce the three parameters of a standard autoconf macro
to one parameter in an APR-specific macro? If so, then -1 --> that
kind of change is why our buildconf setup is so much less portable
than typical configure scripts, and what I have been trying to get
rid of over the past few weeks. Do it the autoconf way or don't do
it at all.
....Roy
Re: FreeBSD and gnu m4
Posted by rb...@covalent.net.
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
-------------------------------------------------------------------------------
Re: FreeBSD and gnu m4
Posted by Greg Stein <gs...@lyra.org>.
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.
>...
> > 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/
Re: FreeBSD and gnu m4
Posted by rb...@covalent.net.
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
-------------------------------------------------------------------------------
Re: FreeBSD and gnu m4
Posted by "Roy T. Fielding" <fi...@ebuilt.com>.
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.
> 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 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
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.
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.
....Roy
Re: FreeBSD and gnu m4
Posted by rb...@covalent.net.
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.
Ryan
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
-------------------------------------------------------------------------------
Re: FreeBSD and gnu m4
Posted by "Roy T. Fielding" <fi...@ebuilt.com>.
> 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
Re: FreeBSD and gnu m4
Posted by rb...@covalent.net.
On Thu, 1 Mar 2001, Roy T. Fielding wrote:
> On Thu, Mar 01, 2001 at 09:39:22PM -0500, Cliff Woolley wrote:
> > On Thu, 1 Mar 2001, Roy T. Fielding wrote:
> >
> > > Correct me if I am wrong, but all these changes and problems are
> > > simply to reduce the three parameters of a standard autoconf macro
> > > to one parameter in an APR-specific macro?
> >
> > That's one way to look at it, yeah, but that doesn't capture all of the
> > benefits. Those three parameters have given us *numerous* subtle bugs due
> > to typos and the like that go undetected on the committer's platform but
> > cause complete build breakage on other platforms. Reducing to one
> > parameter saves the work that causes these bugs.
>
> Then we should fix the cause of that goofyness, which is due to all
> APR defines being set to "0" or "1" instead of undefined/defined.
> Fixing that would remove the cause of all those other subtle typos and
> bugs, in addition to these above, and leave us with a standard autoconf
> function with one parameter.
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.
Ryan
_______________________________________________________________________________
Ryan Bloom rbb@apache.org
406 29th St.
San Francisco, CA 94131
-------------------------------------------------------------------------------
Re: FreeBSD and gnu m4
Posted by "Roy T. Fielding" <fi...@ebuilt.com>.
On Thu, Mar 01, 2001 at 09:39:22PM -0500, Cliff Woolley wrote:
> On Thu, 1 Mar 2001, Roy T. Fielding wrote:
>
> > Correct me if I am wrong, but all these changes and problems are
> > simply to reduce the three parameters of a standard autoconf macro
> > to one parameter in an APR-specific macro?
>
> That's one way to look at it, yeah, but that doesn't capture all of the
> benefits. Those three parameters have given us *numerous* subtle bugs due
> to typos and the like that go undetected on the committer's platform but
> cause complete build breakage on other platforms. Reducing to one
> parameter saves the work that causes these bugs.
Then we should fix the cause of that goofyness, which is due to all
APR defines being set to "0" or "1" instead of undefined/defined.
Fixing that would remove the cause of all those other subtle typos and
bugs, in addition to these above, and leave us with a standard autoconf
function with one parameter.
....Roy
Re: FreeBSD and gnu m4
Posted by Cliff Woolley <cl...@yahoo.com>.
On Thu, 1 Mar 2001, Roy T. Fielding wrote:
> Correct me if I am wrong, but all these changes and problems are
> simply to reduce the three parameters of a standard autoconf macro
> to one parameter in an APR-specific macro?
That's one way to look at it, yeah, but that doesn't capture all of the
benefits. Those three parameters have given us *numerous* subtle bugs due
to typos and the like that go undetected on the committer's platform but
cause complete build breakage on other platforms. Reducing to one
parameter saves the work that causes these bugs.
--Cliff