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 2001/04/06 03:05:57 UTC
Wishes for adjustments in Apache 2.0
As Ryan requested today (because I said on ApacheCon 2001 that I'm still not
very happy with Apache 2.0 ;), here is a quick list of things related to the
distribution source tree and build system which I recognized recently and
which should be fixed:
o distribution tarballs are named httpd-2_0_xx-yyyy.tar.gz
instead of the expected one: httpd-2.0.xx-yyyy.tar.gz
o distribution tarballs are named httpd-2_0_xx-yyyy.tar.gz
but unpack into httpd-2_0_xx instead of httpd-2_0_xx-yyyy. This is both
against the usual conventions for tarballs and complicates packaging (for
RPM you need a extra and ugly "-n httpd-2_0_xx" on the %setup line, etc.)
o the latest httpd-2_0_16-beta.tar.gz ships with a few "logit" files
which seem to be developer logfiles. These should not be distributed
to end-users.
o if a module wants to hook into the build system, it has to
provide its own config.m4. That's fine for modules which ship with Apache
2.0. For externally maintained modules this implies that the end-user has
GNU Autoconf installed. This is both against the principle (Autoconf is a
developer tool) and makes life of end-users more complicated. Not to mention
the problems which arise if the end-users has a different version of
Autoconf installed.
o there is --enable-modules=MODULE-LIST and --enable-mods-shared=MODULE-LIST
but neither of them do actually accept a list of multiple modules AFAIK.
They just accept a single module name and the "all" and "most" keywords.
o the old scripts build/install.sh, build/mkdir.sh and build/buildinfo.sh
should be replaced by a single build/shtool generated with "shtoolize
install mkdir echo" which is more robust and portable.
o the old config.guess and config.sub versions should be replaced
by the latest version from GNU.
o configure --help shows a few lines with wrong indentation (--with-ssl,
--with-mpm, etc.) This should be lined up correctly.
o Under FreeBSD 4.3-RC I get on the compile command line "-D_REENTRANT
-D_THREAD_SAFE -D_REENTRANT -D_THREAD_SAFE", i.e. the thread stuff twice.
Additionally on the linker command there should be a "-pthread"
to make sure under FreeBSD 4 -libc_r is used. And it seems that
the compile flags are not spreaded consistently in the source tree,
i.e., there are areas where the "-D_REENTRANT -D_THREAD_SAFE"
are not present at all. This can lead to problems earlier or later, too.
o On the httpd linker command line I get "-export-dynamic -export-dynamic
-export-dynamic -export-dynamic -export-dynamic -export-dynamic" under
FreeBSD.
o If I unpack httpd-2_0_16-beta.tar.gz twice and in one copy
perform "./configure --enable-modules=most; make; make distclean"
the result is different from a fresh unpack:
$ diff -ru3 httpd-2_0_16.orig httpd-2_0_16
Only in httpd-2_0_16.orig: .deps
Only in httpd-2_0_16: config.nice
Only in httpd-2_0_16.orig: configure
Only in httpd-2_0_16.orig/include: ap_config_auto.h.in
Only in httpd-2_0_16: libtool
Only in httpd-2_0_16/server: exports.c
Only in httpd-2_0_16/srclib/apr/build: rules.mk
Only in httpd-2_0_16/srclib/apr: config.nice
Only in httpd-2_0_16/srclib/apr: libtool
Only in httpd-2_0_16/srclib/apr-util/build: Makefile
Only in httpd-2_0_16/srclib/apr-util/build: rules.mk
Only in httpd-2_0_16/srclib/apr-util/include/private: apu_select_dbm.h
Only in httpd-2_0_16/srclib/apr-util: libtool
Only in httpd-2_0_16/srclib/apr-util/xml/expat: Makefile
Only in httpd-2_0_16/srclib/apr-util/xml/expat/lib: expat.h
Only in httpd-2_0_16/support: dbmmanage
Only in httpd-2_0_16/support: log_server_status
Only in httpd-2_0_16/support: logresolve.pl
Only in httpd-2_0_16/support: phf_abuse_log.cgi
Only in httpd-2_0_16/support: split-logfile
Most important: the "make distclean" also removed the top-level "configure"
script. That should only happen on a "make realclean" (if exists) but never
on a "make distclean".
o spmt_os2 as the name for an OS/2 specific MPM is inconsistent with
the use of just "win32" and "beos" for the other OS specific MPMs.
I think the whole naming of MPMs currently is confusing to end-users.
o In the installation tree there is a bin/httpd.exp which is the
list of exported symbols and definetely not an executable. This has to be
moved to a different location. Under GNU layout this should be placed under
"datadir" (share/) or "sysconfdir" (etc/).
Greetings,
Ralf S. Engelschall
rse@engelschall.com
www.engelschall.com
Re: [PATCH] distclean cleanups
Posted by Justin Erenkrantz <je...@ebuilt.com>.
On Fri, Apr 06, 2001 at 01:41:51AM -0700, Greg Stein wrote:
> apr-util/xml/expat/ is ASF-managed. We should patch it whenever and however
> we like. I'll cross-sync ours with the real Expat. At some point, our needs
> will precisely coincide with the real Expat CVS repository (they don't
> *yet*) and we can completely dump our copy. But until they coincide, we'll
> simply keep a tweaked copy in our repository.
Okay, that's fine - I wasn't sure what the policy was.
> Enough with the black hole already. You mentioned this once before. We all
I didn't mean it as a slight towards anyone - just comical. Sorry for any
offense. I know you all are busy - I don't want to add to anyone's work
load here (especially this week). In fact, I was hoping that I would
lessen others' load by submitting these patches. Again, my apologies.
> The other day, I complained about Mike Abbott's "drive-by patching." Patches
> need a caretaker; dropping them on us and going away is invariably the wrong
> approach.
I don't intend to do that, but feedback (like this) is appreciated every
once in a while. Thanks - I'm not asking for much...
> We discussed using "extraclean" consistently, everywhere. Apache has a
> "cvsclean" target, IIRC. Roy may have tossed it, though. The extraclean
> target is used by quite a few other software packages.
cvsclean isn't there right now. I switched my patch to use extraclean.
> config.nice != config.status
>
> It should *not* be removed by a distclean. Very often, we will rebuild a
> "configure" and want to run it with the same options. config.status isn't
> correct since it corresponds to a different "configure". Thus, we have
> config.nice. And it needs to survive across a distclean.
I realized that - this is why I mentioned it. But, Apache 1.3.x does
delete the config.status file - although it is a different name, config.nice
in Apache 2.0 is equivalent (IMHO) to config.status. I thought I would
submit a patch that tries to follow what has been done before. But, yes,
I agree - config.nice should not be deleted.
> exports.c could go into the EXTRACLEAN_TARGETS because it could (should?) be
> distributed with the tarball. It isn't going to change from one
> configuration to the next, and it is portable
Done - as I said, I wasn't sure where it should go. I guess it needs to
be included with the tarball (it showed up on rse's diff).
> libtool needs to be removed from the EXTRACLEAN.
I knew something would slip by. =-) Thanks.
> The build/* files should NOT be in the top-level Makefile.in. build/ already
> has its own Makefile, with cleaning targets for a bunch of stuff.
I don't see the Makefile.in in the build directories. Am I missing
something?
Thanks. -- justin
Re: [PATCH] distclean cleanups
Posted by Justin Erenkrantz <je...@ebuilt.com>.
On Fri, Apr 06, 2001 at 01:41:51AM -0700, Greg Stein wrote:
> apr-util/xml/expat/ is ASF-managed. We should patch it whenever and however
> we like. I'll cross-sync ours with the real Expat. At some point, our needs
> will precisely coincide with the real Expat CVS repository (they don't
> *yet*) and we can completely dump our copy. But until they coincide, we'll
> simply keep a tweaked copy in our repository.
Okay, that's fine - I wasn't sure what the policy was.
> Enough with the black hole already. You mentioned this once before. We all
I didn't mean it as a slight towards anyone - just comical. Sorry for any
offense. I know you all are busy - I don't want to add to anyone's work
load here (especially this week). In fact, I was hoping that I would
lessen others' load by submitting these patches. Again, my apologies.
> The other day, I complained about Mike Abbott's "drive-by patching." Patches
> need a caretaker; dropping them on us and going away is invariably the wrong
> approach.
I don't intend to do that, but feedback (like this) is appreciated every
once in a while. Thanks - I'm not asking for much...
> We discussed using "extraclean" consistently, everywhere. Apache has a
> "cvsclean" target, IIRC. Roy may have tossed it, though. The extraclean
> target is used by quite a few other software packages.
cvsclean isn't there right now. I switched my patch to use extraclean.
> config.nice != config.status
>
> It should *not* be removed by a distclean. Very often, we will rebuild a
> "configure" and want to run it with the same options. config.status isn't
> correct since it corresponds to a different "configure". Thus, we have
> config.nice. And it needs to survive across a distclean.
I realized that - this is why I mentioned it. But, Apache 1.3.x does
delete the config.status file - although it is a different name, config.nice
in Apache 2.0 is equivalent (IMHO) to config.status. I thought I would
submit a patch that tries to follow what has been done before. But, yes,
I agree - config.nice should not be deleted.
> exports.c could go into the EXTRACLEAN_TARGETS because it could (should?) be
> distributed with the tarball. It isn't going to change from one
> configuration to the next, and it is portable
Done - as I said, I wasn't sure where it should go. I guess it needs to
be included with the tarball (it showed up on rse's diff).
> libtool needs to be removed from the EXTRACLEAN.
I knew something would slip by. =-) Thanks.
> The build/* files should NOT be in the top-level Makefile.in. build/ already
> has its own Makefile, with cleaning targets for a bunch of stuff.
I don't see the Makefile.in in the build directories. Am I missing
something?
Thanks. -- justin
Re: [PATCH] distclean cleanups
Posted by Greg Stein <gs...@lyra.org>.
On Thu, Apr 05, 2001 at 08:19:23PM -0700, Justin Erenkrantz wrote:
> On Fri, Apr 06, 2001 at 03:05:57AM +0200, Ralf S. Engelschall wrote:
> >
> > o If I unpack httpd-2_0_16-beta.tar.gz twice and in one copy
> > perform "./configure --enable-modules=most; make; make distclean"
> > the result is different from a fresh unpack:
>
> These attached patches should be a step in the right direction for getting
> distclean to work as expected. Because these patches apply to different
> repository, I attached them (I hope that is okay). Patches for httpd-2.0,
> apr, and apr-util. I didn't touch expat because Greg or someone else knows
> that better than I - I could submit a patch for this as well, but this isn't
> ASF stuff. If he feels like cleaning it up, Greg could commit it into the
> real expat repository.
apr-util/xml/expat/ is ASF-managed. We should patch it whenever and however
we like. I'll cross-sync ours with the real Expat. At some point, our needs
will precisely coincide with the real Expat CVS repository (they don't
*yet*) and we can completely dump our copy. But until they coincide, we'll
simply keep a tweaked copy in our repository.
> If someone likes these patches, they can commit them.
>
> My own comments before these patches disappear into the black hole:
Enough with the black hole already. You mentioned this once before. We all
have a bunch of things that we're doing, so a lot of times, we'll let
somebody else handle a particular patch. Well, if everybody does that, then
the patch doesn't get handled. That isn't because of any malign intent
towards you, it is simply because we're all quite busy with the things that
interest us and the things that we feel we need to get done. Bitching about
that fact isn't going to get your patch committed any faster.
If your patch doesn't get committed within a week or so, then *resubmit* the
thing. All of us are quite fine with somebody reposting a patch once a week.
At some point, we'll apply it, or we'll reject it.
The other day, I complained about Mike Abbott's "drive-by patching." Patches
need a caretaker; dropping them on us and going away is invariably the wrong
approach.
>...
> I added a simple maintainer-clean target to build/rules.mk and related
> MAINTAINERCLEAN_TARGETS, but the apr/apr-util Makefiles define
> EXTRACLEAN_TARGETS. Shall we standardize this, or has this already been
> discussed? Based on my interpretation, the GNU standards texinfo page
> suggests maintainer-clean. apr defines EXTRACLEAN_TARGETS, but it doesn't
> seem to use them anywhere (could just be missing the reference).
We discussed using "extraclean" consistently, everywhere. Apache has a
"cvsclean" target, IIRC. Roy may have tossed it, though. The extraclean
target is used by quite a few other software packages.
> Although I could see a case for keeping config.nice around even past
> a distclean, these patches remove it. I think you could leave config.nice,
> but I'm not sure what the accepted practice is. Apache 1.3.x deleted the
> config.status (which is really what config.nice is), so that settles it for
> me right now.
config.nice != config.status
It should *not* be removed by a distclean. Very often, we will rebuild a
"configure" and want to run it with the same options. config.status isn't
correct since it corresponds to a different "configure". Thus, we have
config.nice. And it needs to survive across a distclean.
> I'm not sure of the usage of server/exports.c, but I just added it to
> DISTCLEAN_TARGETS. There seems to be a delete-exports target, but I haven't
> taken the time to understand it. I think it is regenerated somewhere, so
> we should delete it when doing a distclean.
exports.c could go into the EXTRACLEAN_TARGETS because it could (should?) be
distributed with the tarball. It isn't going to change from one
configuration to the next, and it is portable
>...
> RCS file: /home/cvspublic/apr/Makefile.in,v
> retrieving revision 1.45
> diff -u -r1.45 Makefile.in
> --- Makefile.in 2001/04/05 03:59:29 1.45
> +++ Makefile.in 2001/04/06 02:51:41
> @@ -27,9 +27,9 @@
> @INCLUDE_RULES@
>
> CLEAN_TARGETS = $(TARGET_EXPORTS)
> -DISTCLEAN_TARGETS = config.cache config.log config.status \
> +DISTCLEAN_TARGETS = config.cache config.log config.status config.nice \
> include/apr.h include/arch/unix/apr_private.h \
> - APRVARS
> + APRVARS libtool build/rules.mk
> EXTRACLEAN_TARGETS = configure libtool aclocal.m4 \
> include/arch/unix/apr_private.h.in
libtool needs to be removed from the EXTRACLEAN.
>...
> RCS file: /home/cvspublic/apr-util/Makefile.in,v
> retrieving revision 1.26
> diff -u -r1.26 Makefile.in
> --- Makefile.in 2001/04/05 04:00:10 1.26
> +++ Makefile.in 2001/04/06 02:52:20
> @@ -14,9 +14,10 @@
> CLEAN_SUBDIRS = . test build
>
> CLEAN_TARGETS = $(TARGET_EXPORTS)
> -DISTCLEAN_TARGETS = config.cache config.log config.status \
> +DISTCLEAN_TARGETS = config.cache config.log config.status config.nice \
> include/private/apu_config.h include/private/apu_private.h \
> - include/apu.h export_vars.sh
> + include/private/apu_select_dbm.h include/apu.h export_vars.sh \
> + libtool build/Makefile build/rules.mk
> EXTRACLEAN_TARGETS = configure libtool aclocal.m4 \
> include/private/apu_config.h.in
As mentioned above, config.nice is an EXTRACLEAN target, if even that. IMO,
I wouldn't even put it in the clean list. That keeps my private options
across all cleaning of my directories.
libtool needs to be removed from the EXTRACLEAN.
The build/* files should NOT be in the top-level Makefile.in. build/ already
has its own Makefile, with cleaning targets for a bunch of stuff.
Cheers,
-g
--
Greg Stein, http://www.lyra.org/
Re: [PATCH] distclean cleanups
Posted by Greg Stein <gs...@lyra.org>.
On Thu, Apr 05, 2001 at 08:19:23PM -0700, Justin Erenkrantz wrote:
> On Fri, Apr 06, 2001 at 03:05:57AM +0200, Ralf S. Engelschall wrote:
> >
> > o If I unpack httpd-2_0_16-beta.tar.gz twice and in one copy
> > perform "./configure --enable-modules=most; make; make distclean"
> > the result is different from a fresh unpack:
>
> These attached patches should be a step in the right direction for getting
> distclean to work as expected. Because these patches apply to different
> repository, I attached them (I hope that is okay). Patches for httpd-2.0,
> apr, and apr-util. I didn't touch expat because Greg or someone else knows
> that better than I - I could submit a patch for this as well, but this isn't
> ASF stuff. If he feels like cleaning it up, Greg could commit it into the
> real expat repository.
apr-util/xml/expat/ is ASF-managed. We should patch it whenever and however
we like. I'll cross-sync ours with the real Expat. At some point, our needs
will precisely coincide with the real Expat CVS repository (they don't
*yet*) and we can completely dump our copy. But until they coincide, we'll
simply keep a tweaked copy in our repository.
> If someone likes these patches, they can commit them.
>
> My own comments before these patches disappear into the black hole:
Enough with the black hole already. You mentioned this once before. We all
have a bunch of things that we're doing, so a lot of times, we'll let
somebody else handle a particular patch. Well, if everybody does that, then
the patch doesn't get handled. That isn't because of any malign intent
towards you, it is simply because we're all quite busy with the things that
interest us and the things that we feel we need to get done. Bitching about
that fact isn't going to get your patch committed any faster.
If your patch doesn't get committed within a week or so, then *resubmit* the
thing. All of us are quite fine with somebody reposting a patch once a week.
At some point, we'll apply it, or we'll reject it.
The other day, I complained about Mike Abbott's "drive-by patching." Patches
need a caretaker; dropping them on us and going away is invariably the wrong
approach.
>...
> I added a simple maintainer-clean target to build/rules.mk and related
> MAINTAINERCLEAN_TARGETS, but the apr/apr-util Makefiles define
> EXTRACLEAN_TARGETS. Shall we standardize this, or has this already been
> discussed? Based on my interpretation, the GNU standards texinfo page
> suggests maintainer-clean. apr defines EXTRACLEAN_TARGETS, but it doesn't
> seem to use them anywhere (could just be missing the reference).
We discussed using "extraclean" consistently, everywhere. Apache has a
"cvsclean" target, IIRC. Roy may have tossed it, though. The extraclean
target is used by quite a few other software packages.
> Although I could see a case for keeping config.nice around even past
> a distclean, these patches remove it. I think you could leave config.nice,
> but I'm not sure what the accepted practice is. Apache 1.3.x deleted the
> config.status (which is really what config.nice is), so that settles it for
> me right now.
config.nice != config.status
It should *not* be removed by a distclean. Very often, we will rebuild a
"configure" and want to run it with the same options. config.status isn't
correct since it corresponds to a different "configure". Thus, we have
config.nice. And it needs to survive across a distclean.
> I'm not sure of the usage of server/exports.c, but I just added it to
> DISTCLEAN_TARGETS. There seems to be a delete-exports target, but I haven't
> taken the time to understand it. I think it is regenerated somewhere, so
> we should delete it when doing a distclean.
exports.c could go into the EXTRACLEAN_TARGETS because it could (should?) be
distributed with the tarball. It isn't going to change from one
configuration to the next, and it is portable
>...
> RCS file: /home/cvspublic/apr/Makefile.in,v
> retrieving revision 1.45
> diff -u -r1.45 Makefile.in
> --- Makefile.in 2001/04/05 03:59:29 1.45
> +++ Makefile.in 2001/04/06 02:51:41
> @@ -27,9 +27,9 @@
> @INCLUDE_RULES@
>
> CLEAN_TARGETS = $(TARGET_EXPORTS)
> -DISTCLEAN_TARGETS = config.cache config.log config.status \
> +DISTCLEAN_TARGETS = config.cache config.log config.status config.nice \
> include/apr.h include/arch/unix/apr_private.h \
> - APRVARS
> + APRVARS libtool build/rules.mk
> EXTRACLEAN_TARGETS = configure libtool aclocal.m4 \
> include/arch/unix/apr_private.h.in
libtool needs to be removed from the EXTRACLEAN.
>...
> RCS file: /home/cvspublic/apr-util/Makefile.in,v
> retrieving revision 1.26
> diff -u -r1.26 Makefile.in
> --- Makefile.in 2001/04/05 04:00:10 1.26
> +++ Makefile.in 2001/04/06 02:52:20
> @@ -14,9 +14,10 @@
> CLEAN_SUBDIRS = . test build
>
> CLEAN_TARGETS = $(TARGET_EXPORTS)
> -DISTCLEAN_TARGETS = config.cache config.log config.status \
> +DISTCLEAN_TARGETS = config.cache config.log config.status config.nice \
> include/private/apu_config.h include/private/apu_private.h \
> - include/apu.h export_vars.sh
> + include/private/apu_select_dbm.h include/apu.h export_vars.sh \
> + libtool build/Makefile build/rules.mk
> EXTRACLEAN_TARGETS = configure libtool aclocal.m4 \
> include/private/apu_config.h.in
As mentioned above, config.nice is an EXTRACLEAN target, if even that. IMO,
I wouldn't even put it in the clean list. That keeps my private options
across all cleaning of my directories.
libtool needs to be removed from the EXTRACLEAN.
The build/* files should NOT be in the top-level Makefile.in. build/ already
has its own Makefile, with cleaning targets for a bunch of stuff.
Cheers,
-g
--
Greg Stein, http://www.lyra.org/
[PATCH] distclean cleanups
Posted by Justin Erenkrantz <je...@ebuilt.com>.
On Fri, Apr 06, 2001 at 03:05:57AM +0200, Ralf S. Engelschall wrote:
>
> o If I unpack httpd-2_0_16-beta.tar.gz twice and in one copy
> perform "./configure --enable-modules=most; make; make distclean"
> the result is different from a fresh unpack:
These attached patches should be a step in the right direction for getting
distclean to work as expected. Because these patches apply to different
repository, I attached them (I hope that is okay). Patches for httpd-2.0,
apr, and apr-util. I didn't touch expat because Greg or someone else knows
that better than I - I could submit a patch for this as well, but this isn't
ASF stuff. If he feels like cleaning it up, Greg could commit it into the
real expat repository.
If someone likes these patches, they can commit them.
My own comments before these patches disappear into the black hole:
The Makefile.in in httpd-2.0 had a lot of stale DISTCLEAN_TARGETS variables,
so I tried to figure out what is still present in the repository.
.deps is removed by build/rules.mk for the distclean target already, so I
guess the directory used for building the tarball was not clean (Ryan?).
I'd suggest adding a "dist" target that does the actual rolling of a
tarball (obviously not the tagging). That way someone can easily
roll a similar tarball (with excluded files and stuff) from the end-user
build system. I don't know if Ryan has finalized the process for the
rolling of a tarball yet. He's the RM... =-)
I added a simple maintainer-clean target to build/rules.mk and related
MAINTAINERCLEAN_TARGETS, but the apr/apr-util Makefiles define
EXTRACLEAN_TARGETS. Shall we standardize this, or has this already been
discussed? Based on my interpretation, the GNU standards texinfo page
suggests maintainer-clean. apr defines EXTRACLEAN_TARGETS, but it doesn't
seem to use them anywhere (could just be missing the reference).
Although I could see a case for keeping config.nice around even past
a distclean, these patches remove it. I think you could leave config.nice,
but I'm not sure what the accepted practice is. Apache 1.3.x deleted the
config.status (which is really what config.nice is), so that settles it for
me right now.
I'm not sure of the usage of server/exports.c, but I just added it to
DISTCLEAN_TARGETS. There seems to be a delete-exports target, but I haven't
taken the time to understand it. I think it is regenerated somewhere, so
we should delete it when doing a distclean.
Most of the other stuff is fairly straightforward.
Enjoy. -- justin
Re; [PATCH] Wishes for adjustments in Apache 2.0
Posted by Justin Erenkrantz <je...@ebuilt.com>.
On Fri, Apr 06, 2001 at 03:05:57AM +0200, Ralf S. Engelschall wrote:
>
> o if a module wants to hook into the build system, it has to
> provide its own config.m4. That's fine for modules which ship with Apache
> 2.0. For externally maintained modules this implies that the end-user has
> GNU Autoconf installed. This is both against the principle (Autoconf is a
> developer tool) and makes life of end-users more complicated. Not to mention
> the problems which arise if the end-users has a different version of
> Autoconf installed.
Totally agree here.
> o configure --help shows a few lines with wrong indentation (--with-ssl,
> --with-mpm, etc.) This should be lined up correctly.
I did the grunt work (see below) - someone with commit access can apply this
(after verifying it works). Most of my cosmetic patches seem to end up in a
black hole - not that I care very much...
> o On the httpd linker command line I get "-export-dynamic -export-dynamic
> -export-dynamic -export-dynamic -export-dynamic -export-dynamic" under
> FreeBSD.
I think Roy might have committed a fix for this.
> o If I unpack httpd-2_0_16-beta.tar.gz twice and in one copy
> perform "./configure --enable-modules=most; make; make distclean"
> the result is different from a fresh unpack:
> $ diff -ru3 httpd-2_0_16.orig httpd-2_0_16
> Most important: the "make distclean" also removed the top-level "configure"
> script. That should only happen on a "make realclean" (if exists) but never
> on a "make distclean".
Yeah, I noticed that playing with 2.0.16. Not good. I may submit a patch
for this if it still happens. -- justin
Index: configure.in
===================================================================
RCS file: /home/cvspublic/httpd-2.0/configure.in,v
retrieving revision 1.142
diff -u -r1.142 configure.in
--- configure.in 2001/04/03 23:47:39 1.142
+++ configure.in 2001/04/06 01:27:58
@@ -152,7 +152,7 @@
[if test "$withval" = "yes"; then AC_MSG_ERROR('option --with-port requires a value (the TCP port number)'); else PORT="$withval"; fi],
[PORT=80])
-AC_ARG_ENABLE(debug,[ --enable-debug Turn on debugging and compile time warnings],
+AC_ARG_ENABLE(debug,[ --enable-debug Turn on debugging and compile time warnings],
[CFLAGS="$CFLAGS -g"; if test "$GCC" = "yes"; then CFLAGS="$CFLAGS -Wall"; fi])
AC_ARG_ENABLE(maintainer-mode,[ --enable-maintainer-mode Turn on debugging and compile time warnings],
Index: modules/tls/config.m4
===================================================================
RCS file: /home/cvspublic/httpd-2.0/modules/tls/config.m4,v
retrieving revision 1.3
diff -u -r1.3 config.m4
--- modules/tls/config.m4 2001/02/12 16:50:21 1.3
+++ modules/tls/config.m4 2001/04/06 01:27:58
@@ -4,7 +4,7 @@
tls_objs="mod_tls.lo openssl_state_machine.lo"
APACHE_MODULE(tls, TLS/SSL support, $tls_objs, , no, [
- AC_ARG_WITH(ssl, [ --with-ssl use a specific SSL library installation ],
+ AC_ARG_WITH(ssl, [ --with-ssl use a specific SSL library installation ],
[
searchfile="$withval/inc/ssl.h"
if test -f $searchfile ; then
Index: server/mpm/config.m4
===================================================================
RCS file: /home/cvspublic/httpd-2.0/server/mpm/config.m4,v
retrieving revision 1.34
diff -u -r1.34 config.m4
--- server/mpm/config.m4 2001/04/03 18:37:07 1.34
+++ server/mpm/config.m4 2001/04/06 01:27:58
@@ -1,7 +1,7 @@
AC_MSG_CHECKING(which MPM to use)
AC_ARG_WITH(mpm,
[ --with-mpm=MPM Choose the process model for Apache to use.
- MPM={beos,threaded,prefork,spmt_os2,perchild}],[
+ MPM={beos,threaded,prefork,spmt_os2,perchild}],[
APACHE_MPM=$withval
],[
if test "x$APACHE_MPM" = "x"; then
[PATCH] distclean cleanups
Posted by Justin Erenkrantz <je...@ebuilt.com>.
On Fri, Apr 06, 2001 at 03:05:57AM +0200, Ralf S. Engelschall wrote:
>
> o If I unpack httpd-2_0_16-beta.tar.gz twice and in one copy
> perform "./configure --enable-modules=most; make; make distclean"
> the result is different from a fresh unpack:
These attached patches should be a step in the right direction for getting
distclean to work as expected. Because these patches apply to different
repository, I attached them (I hope that is okay). Patches for httpd-2.0,
apr, and apr-util. I didn't touch expat because Greg or someone else knows
that better than I - I could submit a patch for this as well, but this isn't
ASF stuff. If he feels like cleaning it up, Greg could commit it into the
real expat repository.
If someone likes these patches, they can commit them.
My own comments before these patches disappear into the black hole:
The Makefile.in in httpd-2.0 had a lot of stale DISTCLEAN_TARGETS variables,
so I tried to figure out what is still present in the repository.
.deps is removed by build/rules.mk for the distclean target already, so I
guess the directory used for building the tarball was not clean (Ryan?).
I'd suggest adding a "dist" target that does the actual rolling of a
tarball (obviously not the tagging). That way someone can easily
roll a similar tarball (with excluded files and stuff) from the end-user
build system. I don't know if Ryan has finalized the process for the
rolling of a tarball yet. He's the RM... =-)
I added a simple maintainer-clean target to build/rules.mk and related
MAINTAINERCLEAN_TARGETS, but the apr/apr-util Makefiles define
EXTRACLEAN_TARGETS. Shall we standardize this, or has this already been
discussed? Based on my interpretation, the GNU standards texinfo page
suggests maintainer-clean. apr defines EXTRACLEAN_TARGETS, but it doesn't
seem to use them anywhere (could just be missing the reference).
Although I could see a case for keeping config.nice around even past
a distclean, these patches remove it. I think you could leave config.nice,
but I'm not sure what the accepted practice is. Apache 1.3.x deleted the
config.status (which is really what config.nice is), so that settles it for
me right now.
I'm not sure of the usage of server/exports.c, but I just added it to
DISTCLEAN_TARGETS. There seems to be a delete-exports target, but I haven't
taken the time to understand it. I think it is regenerated somewhere, so
we should delete it when doing a distclean.
Most of the other stuff is fairly straightforward.
Enjoy. -- justin
Re: Wishes for adjustments in Apache 2.0
Posted by Rodent of Unusual Size <Ke...@Golux.Com>.
Wilfredo Sanchez wrote:
>
> I don't agree that all of the build tool scripts belong in a single
> überscript, though.
Indeed not. We have had that discussion too many times before..
--
#ken P-)}
Ken Coar <http://Golux.Com/coar/>
Apache Software Foundation <http://www.apache.org/>
"Apache Server for Dummies" <http://Apache-Server.Com/>
"Apache Server Unleashed" <http://ApacheUnleashed.Com/>
Re: Wishes for adjustments in Apache 2.0
Posted by Wilfredo Sanchez <ws...@MIT.EDU>.
This is a good list of problems, though I don't think any one of them
looks like a release show-stopper. Many are simply good cleanup items.
I don't think you'll much objection to cleaning them up.
I don't agree that all of the build tool scripts belong in a single
überscript, though.
-Fred