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/
