You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@httpd.apache.org by "Ralf S. Engelschall" <rs...@engelschall.com> on 1998/11/10 13:54:32 UTC
Apache 1.3 and APACI: Points of view
[Long text about APACI and it's history]
Until now I've stayed out of the discussion which started after Lars'
APACI-related commit. But because some of us are saying this and that was the
intent behind APACI it would be good that I give at least my personal point of
view for APACI (as the main author) and the actual intent I personally had in
mind when creating it. So here are a few facts from my personal point of view.
You don't have to comment on them. They are just a few points to clarify what
my personal point of view is.
o Setting up Apache 1.2 was a pain for me in 1997. Not because
it's complicated. More because it's time-consuming (a lot of manual copying)
and error-prone (one forgets to install files). So I've written my own
installation system (BnP) which installed all the time the latest Apache
packages on all webservers I maintain. In March 1998 the beta cycle of
Apache 1.3 was coming to an end and I was still very frustrated about the
fact that setting up an Apache 1.3bX webserver with all bells and whistles
was more complicated than setting up most of the other packages I usually
install. Sure, I had my BnP, but every time a talked to my friends and
colleagues they said: "Hey, why BnP? Why don't you make Apache a better
package!".
o I thought about Apache and the reason why the other packages are
easier to setup and observed that it has mainly to do with one fact: The
others use GNU Autoconf. I love the spirit behind and the quality of GNU
software and used GNU Autoconf for my own packages (ePerl, WML, etc.) for
years. And I always thought I loved GNU Autoconf only for it's flexibility
to create configuration scripts for my packages. But now I actually
discovered that I love GNU Autoconf more for two other reasons:
1. It generates "configure" scripts which provide a uniform and 100%
batch-able interface to the software package. Whether those configure
command lines are pretty or not is not important (sometimes - even for
APACI - they get horrible complicated and read ugly). The fact is that
people are used to it because it's a de-facto standard for Open Source
Software packages. Whenever a user sees a script named "configure" he
smiles and knows: "When I now run `./configure --prefix=/path; make; make
install' I get the package built and installed into /path without
fiddling around with that particular package source. Great!".
2. It usually installs the package _ONLY_ under the specified /path from
--prefix=/path _AND_ uses a well-defined layout there. Sure, this depends
on the Makefile.in the package uses and the experience of the package
author. But usually they to it the correct way. Whether this well-defined
layout is pretty or not is again not important. It's only important that
"make install" doesn't touch anything outside /path and that the
generated layout is always mostly the same. The actual used layout
follows the GNU standards and fit well into 80% of all /usr/local or /opt
hierarchies of Unix platforms. To overcome the remaining 20% GNU Autoconf
usually provides specialized options in addition to --prefix. This means
the average user is happy with --prefix and vendor package maintainer are
happy becasue of those additional options.
o So we discussed (again) in March 1998 whether to use GNU Autoconf or
not for Apache 1.3. The decision was that it's both to late in the 1.3 cycle
and to much to change the complete configuration scheme for 1.3 into an GNU
Autoconf based one. At first I was frustrated again. But then I looked at
our existing configuration stuff: src/Configure + src/helpers/* +
Makefile.tmpls. They were a lot of deficiencies. But I had the essential
idea:
Before I already observed that the configuration internals generated by GNU
Autoconf are not really important. It's just one point. More important are
the other two points: The configure interface and the install procedure. So
I decided in March 1998 to solve the situation by a different approach
(which I then followed very strictly):
1. Overhaul and cleanup the src/Configure and Makefile.tmpl files to
at least closely have the internal functionality usually provided by GNU
Autoconf. This was needed for a lot of technical reasons. For instance we
needed the $(SRCDIR) variable, we needed a way to add Dynamic Shared
Object (DSO) support later, etc.
2. Write a frontend (a wrapper) to src/Configure named "configure"
which resembles the GNU Autoconf interface but uses the now cleaned up
internals of src/Configure as the backend.
3. Write a top-level Makefile.tmpl which is configured by
"configure" and provides an all-in-one Apache installation following
again the GNU Autoconf way, i.e. which uses the filesystem layout for
installing described in GNU standards.
4. DON'T CHANGE ANYTHING inside src/ to integrate this new stuff. Because
only this way I can overcome the main restriction the group settled:
APACI has to be optional (i.e. the old 1.2 configuration way has to be
still useable) and APACI should be an addition which can be easily
reviewed for comitting.
o Ok, after I've spent really a lot of time in March and April 1998
to follow the above points APACI was ready. We had a very long discussion
about this stuff and observed the following two major points on which a
decision has to be made:
1. We gain a lot of functionality which was missing for a long time
(like the installation procedure) and gain the ability to provide an
interface a lot of people expect and are used to.
2. We have one major drawback: because we don't want to drop support
for the src/Configure script as an _interface_ (as a backend it would be
always there) we would have to life with two configuration
interfaces. This would confuse some people.
We finally decided that the functionality point is more worth than the
confusion point. So we integrated APACI into Apache 1.3b7 (AFAIK the version
number).
o Over the forthcoming months APACI become known to the Apache community
and popular. Actually such popular that those of us who initially voted -0
for APACI (for various good reasons: because of the confusion point, because
they hate GNU Autoconf, because they love the old 1.2 configure way, whatever)
noticed that a evolution takes place and had a problem with it: People
think APACI is the only/official/better/whatever way of configuring
Apache. So the APACI-adversaries blame (in harmless form, of course - but
always ;-) on APACI when possible. But in the user community I saw the
following feedback:
1. GOOD: Most of the webmasters were happy about APACI. Most of the time
not because they love GNU Autoconf from the users point of view (the
interface). More because this way they can setup their Apache
installation a lot more easily. And more important: They can setup it on
a lot of webservers in parallel without much more effort because of the
100% batch-capability.
2. GOOD: All (AFAIK) package vendors were happy and switched to APACI.
Not because of the installation procedure. More because of the interface
which doesn't require any source patching. Sure, for instance the
apache13 port of FreeBSD and the various RPMs out there still patch the
source (e.e. FreeBSD insert some limits, etc.), but the patching was
dramatically reduced for Apache 1.3 with APACI.
3. BAD: Some webmasters/users (as we expected) were confused by the
two existing configuration scripts. Sure, it was our requirement (APACI
is optional), but it is confusing for some people. Especially for those
who were used to the src/Configure way of editing src/Configuration.
4. Hmmmm: Even some Apache developers still ignore APACI totally.
That's not a problem in general. Every one is free to use the non-APACI
way - even Apache developers. It's more a problem because those are the
developers who always start the against-APACI discussions again from time
to time (as it was the case this time) ;-)
o Although I recognize the confusion problem I still have to conclude for
myself that APACI was worth the effort. Because the benefits counted and
still count (at least IMHO) more than the drawbacks. So up to this point I
still see no big problem for APACI in Apache 1.3. It solved the frustrating
situation out of which it was born and proved to be stable, portable and
still fully functional.
o About a few other dicussion points (some cites are only symbolic):
1. "it's stupid to have two configuration interfaces":
Correct, also my opinion in general. But that doesn't necessarily imply
that APACI is the interface which makes the trouble. The same way one can
argue that the src/Configure interface creates the confusion. No one
prevents us from renaming src/Configure and using it only as a backend.
It was our decision that we still want to provide src/Configure as a
_frontend_. So we shouldn't think the confusion is inherent because
APACI exists. It's also because we don't wanted to drop support for
src/Configure.
2. "it seems to be becoming the de facto build method":
Ok, but doesn't this mean it proved to be a good build method? I think it
became the de facto build method because it provided an interface the
users _expected_. Not because we pushed it.
3. "For Apache 2.0 we want GNU Autoconf but for Apache 1.3 APACI
should not be the preferred build method": This point is confusing to me.
Some of us accept GNU Autoconf for Apache 2.0 but not APACI for Apache
1.3 at the same time. Although the interface is mostly the same. Sorry,
this point of view I don't understand.
4. "none of this APACI stuff should survive in the 2.0 tree".
I think a lot of APACI _AND_ src/helpers/* should survive in the 2.0
tree. I'll write a little bit more about this below.
5. "I just find it odd that the people who have worked so hard on providing
this functionality (mostly but not entirely Ralf) haven't devoted at
least a little effort to getting the real thing to work in the 2.0 tree":
First that's mainly because initially the apache-2.0 tree was created
with the stuff from src/ only. Second whether the apache-2.0 tree is the
code start for Apache 2.0 is still under discussion. And third (the real
answer): I personally think we have to start the configuration mechnism
from scratch inside an empty source tree.
o Now a new star is on the horizon: Apache 2.0. This is a new playground
for hot dicussions and one of them are that people now think GNU Autoconf
should be used. Fine in general. But my experience with GNU Autoconf on
the one side and a handmade one like APACI+src/Configure on the other
side showed my that it's not such easy. I even want to give the
following statement:
Using just GNU Autoconf + GNU Automake + GNU libtool for Apache 2.0
and thinking we're then solved our problems is silly.
Yeah, right. Even I'm a GNU Autoconf fan I think it's not such easy. I've
thought a lot of time about a really good configuration scheme some months
ago (in July 1998) and my personal conclusion was that it's the wrong way to
just kick in those tools into Apache 2.0. The reasons are very technically
and I've to search for my notices myself in order to explain them correctly.
For instance one thing I remember is that for DSO situation and the
Build-outside-the-Apache-source-tree situation (like APXS) those tools are
not sufficient when used as frontends.
So, my personal opinion for Apache 2.0 is the following:
We should start the configuration mechanism from scratch, i.e. with a
really empty source tree. And we should use Autoconf+Automake+libtool as
backends. But only as backends. As the frontend IMHO we should again write a
handmade script like APACI's configure script. I volunteer to develop the
complete configuration and build mechanism for Apache 2.0 in a few months
this way when the group wants it this way, of course.
Ok, this was more text than I wanted to write, but perhaps we can extract some
pieces out of it to write a little APACI-background document when it's needed.
(don't know whether it's needed). Thanks for reading my opinions. But feel
free to not share them ;-)
Greetings,
Ralf S. Engelschall
rse@engelschall.com
www.engelschall.com
Re: Apache 1.3 and APACI: Points of view
Posted by Rodent of Unusual Size <Ke...@Golux.Com>.
I started a detailed reply to this, but decided against it.
Was APACI a worthwhile effort? I think so. Is it good that
it's out there? IMO, yes. Then what's the problem? I for one
am not sure. There's just something about this issue that
polarises us. :-)
One thing that bothers me personally is the impression I have
(possibly unfounded) that some of us tell users asking for
configuration assistance, "Nope, sorry -- if you want to use
APACI I can't help you," and others of us tell them, "Why
are you using that crufty src/Configure when configure will
do it all for you?"
{Wistfully} It would be nice if we could all get behind a
single message..
I really ought to shut up on the technical side of the subject
until I've given APACI a serious try and can develop an
informed opinion about the relative merits. On the
philosophical side.. well, I just described my opinion
there. :-D
#ken P-)}
Ken Coar <http://Web.Golux.Com/coar/>
Apache Group member <http://www.apache.org/>
"Apache Server for Dummies" <http://Web.Golux.Com/coar/ASFD/>
Re: Apache 1.3 and APACI: Points of view
Posted by Randy Terbush <ra...@Covalent.NET>.
Without requoting all of Ralf's message regarding APACI...
I think that it would be good to phase out the use of the 'Configure'
script by making sure that 'configure -file' worked as it does in
'Configure' or that a 'configure' without parameters looked for a
'Configuration.tmpl'. It would be possible to greatly simplify the
format of 'Configuration.tmpl' while we are at it.
I also think that we need to revert back to --compat layout as the
default. KISS
-Randy
Re: Apache 1.3 and APACI: Points of view
Posted by Ben Laurie <be...@algroup.co.uk>.
Randy Terbush wrote:
>
> I'll respond to the original message after this, but I would like to
> voice my strong support to make --compat the default in APACI. The
> "GNU path layout" (if that's what it is) is a nightmare to support.
>
> +1 to make --compat the default.
+1
Cheers,
Ben.
--
Ben Laurie |Phone: +44 (181) 735 0686| Apache Group member
Freelance Consultant |Fax: +44 (181) 735 0689|http://www.apache.org/
and Technical Director|Email: ben@algroup.co.uk |
A.L. Digital Ltd, |Apache-SSL author http://www.apache-ssl.org/
London, England. |"Apache: TDG" http://www.ora.com/catalog/apache/
Re: Apache 1.3 and APACI: Points of view
Posted by Ed Korthof <ed...@bitmechanic.com>.
On 11 Nov 1998, Randy Terbush wrote:
> I'll respond to the original message after this, but I would like to
> voice my strong support to make --compat the default in APACI. The
> "GNU path layout" (if that's what it is) is a nightmare to support.
>
> +1 to make --compat the default.
I'd also love to see --compat become the default in APACI. The long path
names which the "GNU path layout" creates are a pain to deal with as a
user.
Ed
Re: Apache 1.3 and APACI: Points of view
Posted by Randy Terbush <ra...@Covalent.NET>.
I'll respond to the original message after this, but I would like to
voice my strong support to make --compat the default in APACI. The
"GNU path layout" (if that's what it is) is a nightmare to support.
+1 to make --compat the default.
Martin Kraemer <ma...@mch.sni.de> writes:
> On Tue, Nov 10, 1998 at 02:54:53PM -0500, Jim Jagielski wrote:
> > I will try to sum up my POV. As I do so, I want people to
> > mull over in their minds the 2 mutually exclusive statements above:
> > "Every one is free to use the non-APACI way" and "we stop supporting
> > the old interface." If this means during 1.3.x or even 1.x.x, then I
> > think it's a mistake.
>
> 100% agreed. I think nobody really thought they wanted to drop Configure.
> (definitely not in 1.x).
>
> > I think for many people, it was
> > becoming obvious that the end goal was, in the 1.3.x development
> > cycle, to make APACI the official build method yet in a very subtle
> > way. Hence the debate.
>
> I'm not so sure. As configure is a layer around Configure (and not a
> replacement), I think even Ralf's intention was not to drop the "old"
> interface within the 1.x life line, but instead use it to our advantage.
> (Simple detection/configuration of the DSO stuff however was difficult
> with the standard solution, so the apaci configure HAD to exceed its
> "limits" in this respect).
>
> > Do I think APACI should replace Configure? No. At least not in the 1.x.x
> > cycle. For 2.0, the ball's up in the air.
>
> That's how I see it as well.
>
> > One suggestion would maybe help. If ./configure is called with no arguments,
> > and there is a src/Configuration file, that ./configure simply feed
> > that right to Configure and that it not "override" anything... So that
> > ./configure and src/Configure would produce the EXACT same binary.
>
> That would mean especially that the default paths are the traditional...
> #define HTTPD_ROOT "/usr/local/apache"
> #define SERVER_CONFIG_FILE "conf/httpd.conf"
> #define RESOURCE_CONFIG_FILE "conf/srm.conf"
> #define TYPES_CONFIG_FILE "conf/mime.types"
> #define ACCESS_CONFIG_FILE "conf/access.conf"
> #define DEFAULT_XFERLOG "logs/access.log"
> #define DEFAULT_XFERLOG "logs/access_log"
> #define DEFAULT_ERRORLOG "logs/error.log"
> #define DEFAULT_ERRORLOG "logs/error_log"
> #define DEFAULT_PIDLOG "logs/httpd.pid"
> #define DEFAULT_SCOREBOARD "logs/apache_runtime_status"
> #define DEFAULT_LOCKFILE "logs/accept.lock"
>
> which could be the default, with the GNU style paths being available via
> a configure option.
>
> Yes, I'd +1 that as well. And it wouldn't even be much harder than
> making "--compat" the default (and omitting the creation of
> Configure.apaci)
>
> Martin
> --
> <Ma...@Mch.SNI.De> | Siemens Information and
> Phone: +49-89-636-46021 | Communication Products
> FAX: +49-89-636-47816 | 81730 Munich, Germany
Re: Apache 1.3 and APACI: Points of view
Posted by Lars Eilebrecht <La...@unix-ag.org>.
According to Martin Kraemer:
> That would mean especially that the default paths are the traditional...
> #define HTTPD_ROOT "/usr/local/apache"
> #define SERVER_CONFIG_FILE "conf/httpd.conf"
> #define RESOURCE_CONFIG_FILE "conf/srm.conf"
> #define TYPES_CONFIG_FILE "conf/mime.types"
> #define ACCESS_CONFIG_FILE "conf/access.conf"
> #define DEFAULT_XFERLOG "logs/access.log"
> #define DEFAULT_XFERLOG "logs/access_log"
> #define DEFAULT_ERRORLOG "logs/error.log"
> #define DEFAULT_ERRORLOG "logs/error_log"
> #define DEFAULT_PIDLOG "logs/httpd.pid"
> #define DEFAULT_SCOREBOARD "logs/apache_runtime_status"
> #define DEFAULT_LOCKFILE "logs/accept.lock"
>
> which could be the default, with the GNU style paths being available via
> a configure option.
+1 to use these paths as the default APACI paths and add an extra
configure option for GNU-style paths.
ciao...
--
Lars Eilebrecht - I may not be totally perfect,
sfx@unix-ag.org - but parts of me are excellent.
http://www.home.unix-ag.org/sfx/
Re: Apache 1.3 and APACI: Points of view
Posted by Martin Kraemer <ma...@mch.sni.de>.
On Tue, Nov 10, 1998 at 02:54:53PM -0500, Jim Jagielski wrote:
> I will try to sum up my POV. As I do so, I want people to
> mull over in their minds the 2 mutually exclusive statements above:
> "Every one is free to use the non-APACI way" and "we stop supporting
> the old interface." If this means during 1.3.x or even 1.x.x, then I
> think it's a mistake.
100% agreed. I think nobody really thought they wanted to drop Configure.
(definitely not in 1.x).
> I think for many people, it was
> becoming obvious that the end goal was, in the 1.3.x development
> cycle, to make APACI the official build method yet in a very subtle
> way. Hence the debate.
I'm not so sure. As configure is a layer around Configure (and not a
replacement), I think even Ralf's intention was not to drop the "old"
interface within the 1.x life line, but instead use it to our advantage.
(Simple detection/configuration of the DSO stuff however was difficult
with the standard solution, so the apaci configure HAD to exceed its
"limits" in this respect).
> Do I think APACI should replace Configure? No. At least not in the 1.x.x
> cycle. For 2.0, the ball's up in the air.
That's how I see it as well.
> One suggestion would maybe help. If ./configure is called with no arguments,
> and there is a src/Configuration file, that ./configure simply feed
> that right to Configure and that it not "override" anything... So that
> ./configure and src/Configure would produce the EXACT same binary.
That would mean especially that the default paths are the traditional...
#define HTTPD_ROOT "/usr/local/apache"
#define SERVER_CONFIG_FILE "conf/httpd.conf"
#define RESOURCE_CONFIG_FILE "conf/srm.conf"
#define TYPES_CONFIG_FILE "conf/mime.types"
#define ACCESS_CONFIG_FILE "conf/access.conf"
#define DEFAULT_XFERLOG "logs/access.log"
#define DEFAULT_XFERLOG "logs/access_log"
#define DEFAULT_ERRORLOG "logs/error.log"
#define DEFAULT_ERRORLOG "logs/error_log"
#define DEFAULT_PIDLOG "logs/httpd.pid"
#define DEFAULT_SCOREBOARD "logs/apache_runtime_status"
#define DEFAULT_LOCKFILE "logs/accept.lock"
which could be the default, with the GNU style paths being available via
a configure option.
Yes, I'd +1 that as well. And it wouldn't even be much harder than
making "--compat" the default (and omitting the creation of
Configure.apaci)
Martin
--
<Ma...@Mch.SNI.De> | Siemens Information and
Phone: +49-89-636-46021 | Communication Products
FAX: +49-89-636-47816 | 81730 Munich, Germany
Re: Apache 1.3 and APACI: Points of view
Posted by Ben Hyde <bh...@pobox.com>.
Ralf S. Engelschall writes:
A wonderful essay about APACI, thanks!
> 4. Hmmmm: Even some Apache developers still ignore APACI totally.
> That's not a problem in general. Every one is free to use the non-APACI
> way - even Apache developers. ...
Speaking from personal experience I didn't switch for a long time. I
had built a huge Rube Goldberg device out of sed and shell scripts
to get from the sources to my various builds and installs. I had no
desire to revisit my hairball. For similar reasons I still haven't
started using the build outside the source tree stuff even though it
would make my mechanism so much simpler.
I suspect that is typical of most older Apache users and sites, hence
we our shoes are nailed to the floor and we have to support the old
API. Have I mentioned that I think the new API is so much better.
The commercial solution to this is to "defer short-term pleasure for
long-term gain." (I live in Puritan New England too.) Warn the users
and then wack them on the next major or minor release. At that time
we stop supporting the old interface. It is always cruel in the short
term to abandon an interface, but it's very taxing in the long run to
maintain both or and fatal to decline to have improve things.
- ben
Re: Apache 1.3 and APACI: Points of view
Posted by Greg Stein <gs...@lyra.org>.
Rasmus Lerdorf wrote:
>
> > Using just GNU Autoconf + GNU Automake + GNU libtool for Apache 2.0
> > and thinking we're then solved our problems is silly.
> >...
>
> I really can't think of anything that can't be done within the confines of
> a real autoconf/automake/libtool setup. I really do think the front-end
> ...
Python allows you to easily include new modules in the compilation. It
also allows for "outside-the-source-tree" compilation of shared modules.
Python uses a standard autoconf script for setting up the
platform-specific things. After that, you tweak Modules/Setup to
fine-tune the module set, then add your custom modules to
Modules/Setup.local. Then you type "make".
The main point is the "configure" is still the front end. I believe you
could refine things to avoid Setup{,.local}. Note that the primary
reason Setup exists is to provide link directives and C_FLAGS; Apache
uses *.module. Keeping a *.module approach may allow you to skip the
Setup stuff.
Just wanted to mention the Python setup system, as it provides a
mechanism similar to what you're looking for (internal/external building
of modules/DSOs, autoconf-based). I'm more than willing to provide
detailed Q&A support to anybody who decies to look into it.
Cheers,
-g
--
Greg Stein, http://www.lyra.org/
Re: Apache 1.3 and APACI: Points of view
Posted by Rasmus Lerdorf <ra...@lerdorf.on.ca>.
> Using just GNU Autoconf + GNU Automake + GNU libtool for Apache 2.0
> and thinking we're then solved our problems is silly.
>
> Yeah, right. Even I'm a GNU Autoconf fan I think it's not such easy. I've
> thought a lot of time about a really good configuration scheme some months
> ago (in July 1998) and my personal conclusion was that it's the wrong way to
> just kick in those tools into Apache 2.0. The reasons are very technically
> and I've to search for my notices myself in order to explain them correctly.
> For instance one thing I remember is that for DSO situation and the
> Build-outside-the-Apache-source-tree situation (like APXS) those tools are
> not sufficient when used as frontends.
>
> So, my personal opinion for Apache 2.0 is the following:
>
> We should start the configuration mechanism from scratch, i.e. with a
> really empty source tree. And we should use Autoconf+Automake+libtool as
> backends. But only as backends. As the frontend IMHO we should again write a
> handmade script like APACI's configure script. I volunteer to develop the
> complete configuration and build mechanism for Apache 2.0 in a few months
> this way when the group wants it this way, of course.
I really can't think of anything that can't be done within the confines of
a real autoconf/automake/libtool setup. I really do think the front-end
should be a normal generated configure script. You can hook all sorts of
custom scripts and checks into it. Like I posted yesterday, the most we
would probably have to do is pre-parse a template file and generate
configure.in in order to solve the issue of third-party modules getting
hooked in easily. The Build-outside-the-Apache-source-tree situation you
talk about can be handled in this manner. As for DSO, you would have to
explain in more detail what exactly you see as the issue here. I am quite
sure that whatever it is, we can come up with a bit of m4 magic to solve
it.
-Rasmus