apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Greg Stein <gst...@lyra.org>
Subject Re: [PATCH] distclean cleanups
Date Fri, 06 Apr 2001 08:41:51 GMT
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/

Mime
View raw message