Re: Shouldn't the definition of maintainer-clean be changed?
Hello Benoit, Please limit followups to this message to *ONE* group only, except as noted below, for simplicity let's say as this is where things started off. I've already thrown out a couple of lists. * Benoit Sigoure wrote on Mon, Mar 19, 2007 at 10:42:09PM CET: > > Here is a first patch proposal that adds a --clean option to autoreconf, > autoconf, autoheader, aclocal, automake and libtoolize. > I don't know if I was meant to send this mail to the -patches > mailing lists Yes, please. And please make it one patch per message, each to its list, no cross posting. Let's not discuss patches here: casual readers should not carry the burden of getting patch nitpicking noise. > There is more work to be done: filling ChangeLog/NEWS entries, > documenting this in manuals, supporting autopoint and maybe some other > auto I might have omitted, and most important I think: adding > tests (new feature = new bugs => new tests). Yes. Will you write all or some of this as well? Further, we need copyright assignment from you; I'll contact you off-list about this. > Also I noticed that there is one thing that remains after a autoreconf > --clean: the autom4te.cache directory. But I don't quite know at which > stage and which tool ought to remove it. Not sure either. Probably either not at all, or either tool which directly or indirectly invokes autom4te should invoke `autom4te --clean', but it would be good if autoreconf took care to invoke it at most once (with the last command, for efficiency, and not if the cache is not package-local!). I like the idea not to put this in a Makefile rule: the tools are where the information is at, and also we don't run into nasty rebuilding issues due to a recursive `make' instance missing files already cleaned. Patches don't look so bad at first sight, a couple of nits below that haven't been addressed yet. You may want to note (or prevent) that using `autoreconf --clean' on the packages Automake and Libtool themselves will leave them in an undesirable state (because in those packages, some of the files you remove are native). Similar may hold for Autoconf and eventually Gettext. [ autoreconf.in ] > +# &run_make ([TARGET]) > +# Please align underlining with the line above it. ;-) > --- libtool/libtoolize.m4sh 9 Mar 2007 15:08:43 - 1.60 > +++ libtool/libtoolize.m4sh 19 Mar 2007 21:04:29 - [...] > @@ -729,6 +735,12 @@ > +if $opt_clean; then > + rm -f "$my_destfile" > + my_return_status=$? At least with --dry-run, it would be helpful to see what's being removed here. Probably also without it. Not sure if similar holds for some of the other tools. Cheers, and thanks much for your efforts, Ralf ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: Shouldn't the definition of maintainer-clean be changed?
Not knowing the guts of this, my only complaint has to do
with the help text for ``--clean'' and the lack of consistency
WRT ``-c'' being an acceptable alias for it.
Benoit Sigoure wrote:
> Index: autoconf/bin/autoconf.as
> ===
> RCS file: /sources/autoconf/autoconf/bin/autoconf.as,v
> retrieving revision 1.24
> diff -u -r1.24 autoconf.as
> --- autoconf/bin/autoconf.as 4 Jan 2007 16:43:06 - 1.24
> +++ autoconf/bin/autoconf.as 19 Mar 2007 21:04:17 -
> @@ -33,6 +33,7 @@
>-v, --verbose verbosely report processing
>-d, --debug don't remove temporary files
>-f, --force consider all files obsolete
> + --clean remove all files otherwise installed by autoconf
drop the word, "otherwise" or "all" or see below. :)
> Index: autoconf/bin/autoheader.in
> ===
> RCS file: /sources/autoconf/autoconf/bin/autoheader.in,v
> retrieving revision 1.147
> diff -u -r1.147 autoheader.in
> --- autoconf/bin/autoheader.in4 Jan 2007 16:43:06 - 1.147
> +++ autoconf/bin/autoheader.in19 Mar 2007 21:04:17 -
> @@ -70,6 +70,7 @@
>-h, --help print this help, then exit
>-V, --versionprint version number, then exit
>-v, --verboseverbosely report processing
> + --clean remove the files that would otherwise be created
Here, "otherwise" works. However, the descriptions ought to be the same.
I think simply, ``remove files installed by ${program}'' everywhere.
> Index: autoconf/bin/autoreconf.in
> ===
> RCS file: /sources/autoconf/autoconf/bin/autoreconf.in,v
> retrieving revision 1.137
> diff -u -r1.137 autoreconf.in
> --- autoconf/bin/autoreconf.in4 Jan 2007 16:43:06 - 1.137
> +++ autoconf/bin/autoreconf.in19 Mar 2007 21:04:17 -
> @@ -74,6 +74,7 @@
>-d, --debug don't remove temporary files
>-f, --force consider all files obsolete
>-i, --installcopy missing auxiliary files
> + -c, --clean remove auxiliary files
Another variation? WRT ``-c'', either all have the short option
or none do, please.
> Index: automake/aclocal.in
> ===
> RCS file: /sources/automake/automake/aclocal.in,v
> retrieving revision 1.140
> diff -u -r1.140 aclocal.in
> --- automake/aclocal.in 14 Oct 2006 17:40:25 - 1.140
> +++ automake/aclocal.in 19 Mar 2007 21:04:23 -
> @@ -861,6 +880,7 @@
>changed (implies --install and --dry-run)
>--dry-run pretend to, but do not actually update any file
>--force always update output file
> + -c, --clean remove the files that would otherwise be
> generated
consistency, consistency and more consistency, without good reason otherwise
anyway.
> Index: libtool/libtoolize.m4sh
> ===
> RCS file: /sources/libtool/libtool/libtoolize.m4sh,v
> retrieving revision 1.60
> diff -u -r1.60 libtoolize.m4sh
> --- libtool/libtoolize.m4sh 9 Mar 2007 15:08:43 - 1.60
> +++ libtool/libtoolize.m4sh 19 Mar 2007 21:04:29 -
> @@ -39,6 +39,7 @@
> # -n, --dry-run print commands rather than running them
> # -f, --force replace existing files
> # -i, --install copy missing auxiliary files
> +# --clean remove auxiliary files
___
http://lists.gnu.org/mailman/listinfo/libtool
Re: Shouldn't the definition of maintainer-clean be changed?
Quoting Bruce Korb <[EMAIL PROTECTED]>: Not knowing the guts of this, my only complaint has to do with the help text for ``--clean'' and the lack of consistency WRT ``-c'' being an acceptable alias for it. Yeah you're right, the message should be consistent in the different programs. What about keeping: "--clean remove the files that would otherwise be created" Actually the message might be misleading because the tool might remove files that are already installed and that wouldn't be created because of that... I thought that autoreconf deserved to have `-c' as a short option for `--clean' because autoreconf has only few options ATM and since people are used to do `autoreconf -fvi' it would be convenient to write `autoreconf -fvc'. The other tools have many more configuration options and I wasn't sure that adding `-c' wouldn't be problematic / conflict with already existing options. aclocal wasn't meant to have the `-c' option. -- SIGOURE Benoit aka Tsuna _ /EPITA\ Promo 2008, LRDE ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: Shouldn't the definition of maintainer-clean be changed?
Benoit Sigoure wrote: > Quoting Bruce Korb <[EMAIL PROTECTED]>: > >> Not knowing the guts of this, my only complaint has to do >> with the help text for ``--clean'' and the lack of consistency >> WRT ``-c'' being an acceptable alias for it. >> > > Yeah you're right, the message should be consistent in the different > programs. > What about keeping: > "--clean remove the files that would otherwise be created" > Actually the message might be misleading because the tool might remove > files > that are already installed and that wouldn't be created because of that... --clean remove the files that this program could otherwise recreate Naw. It isn't misleading enough to need to be so excruciatingly correct that it becomes difficult to understand the intention. Shorter is better, but your suggestion reads fine to me. Precision is what man pages and info docs are about. > I thought that autoreconf deserved to have `-c' as a short option for > `--clean' > because autoreconf has only few options ATM and since people are used to do > `autoreconf -fvi' it would be convenient to write `autoreconf -fvc'. The > other > tools have many more configuration options and I wasn't sure that adding > `-c' > wouldn't be problematic / conflict with already existing options. Just a consistency thing: ``without good reason otherwise'' conflict qualifies as a "good reason". :) Cheers - Bruce ___ http://lists.gnu.org/mailman/listinfo/libtool
