Shouldn't the definition of maintainer-clean be changed?

View: New views
11 Messages — Rating Filter:   Alert me  

Shouldn't the definition of maintainer-clean be changed?

by Stepan Kasal :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message

Hello,
  the standards define `maintainer-clean' as a target which is only a
slightly different from distclean.  Besides files cleaned by
distclean, it delets *.c files generated by bison, manual pages
generated by latex2man, etc.

For details, see my post here:
http://lists.gnu.org/archive/html/autoconf/2007-03/msg00043.html

But people tend to guess that this target must be the opposite to
bootstrapping from CVS.

I witnessed that such a great names as Bob Proulx and Ralf Wildenhues
interpreted maintainer-clean this way, see the thread cited above.

Moreover, I noticed that AutoGen tries to use maintainer-clean in
this twisted way.

Another example: when I submitted a patch that removed Makefile.in
from MAINTAINERCLEANFILES to HAL, I got told that using
`maintainer-clean' to delete everything generated by autotools has
become a ``common practice'':
http://lists.freedesktop.org/archives/hal/2007-March/007667.html

I'm afraid that this might become a big mess.  I think that the GNU
standardization crew might help here.

There is a strong need for an un-bootstrap.  Which command shouls
fill the gap?

If `make maintainer-clean', then the GNU Standards should be changed
to reflect this.  The obvious disadvantage is that if the
bootstrap&&configure does not finish, maintainer-clean is not usable.

Or we could implement --clean options to autoconf, automake, ...
all the way until we have `autoreconf --clean' and until it is
trivial to implement `bootstrap.sh --clean'.

I'm looking forward to hear your opinions.

Have a nice day,
        Stepan Kasal



Re: Shouldn't the definition of maintainer-clean be changed?

by Bob Proulx :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message

Hello Stepan,

Apologies to all for continuing the large crossposting.  I am not
subscribed to those lists.

Stepan Kasal wrote:
> For details, see my post here:
> http://lists.gnu.org/archive/html/autoconf/2007-03/msg00043.html
>
> But people tend to guess that this target must be the opposite to
> bootstrapping from CVS.

First off let me say that I was perfectly aware of the standards for
make maintainer-clean when I posted my response to that message.
There is no standard target to perform the desired operation.  That
poster had a very particular set of needs.  My suggestion there did
not in any way reflect a "standard" use of automake or use of the gnu
standards.  It was a very targeted (ab)use of the tool.  I knew that.
I was not proposing a modification of the standards.

The user was wanting to do something non-standard, but not
unreasonable, and expanding upon using the MAINTAINERCLEANFILES seemed
like the easiest way to accomplish that.  I don't think the user had
any intention of distributing the code as a GNU project.

> Moreover, I noticed that AutoGen tries to use maintainer-clean in
> this twisted way.

I have not looked at AutoGen nor how it is using these tools.

> Another example: when I submitted a patch that removed Makefile.in
> from MAINTAINERCLEANFILES to HAL, I got told that using
> `maintainer-clean' to delete everything generated by autotools has
> become a ``common practice'':
> http://lists.freedesktop.org/archives/hal/2007-March/007667.html

A quote from Jon McCann:
> > I suspect the reason that so many people use this practice is that
> > it solves a very common problem for maintainers, namely: how to
> > clean all files generated by autogen.sh.

I found that a quite reasonable statement.  The practical concerns of
needing a clean target win over the philosophical desire to
standardize but not having a useful standardized operation to use.  I
agree that as a GNU project it should follow the standardized use of
the defined targets.  It is a shame to remove functionality not
otherwise provided in order to do this.  In defense when using the
maintainer targets you are assuming the role of a maintainer and more
technical capability is assumed and often required in that case.  I
doubt this issue is actually causing a real problem.

> I'm afraid that this might become a big mess.  I think that the GNU
> standardization crew might help here.

I respectfully suggest that a standards committee driving design may
not be the best way to do this.  It would be better to implement the
new behavior first and then after it is proven useful and effective
then drive changing the standards to use it.

> There is a strong need for an un-bootstrap.  Which command shouls
> fill the gap?

It would be good to have some improved functionality in this area.
See also my posting asking for a clean target for generated source
files.  [All it needs is someone to actually do the work. :-)]

  http://lists.gnu.org/archive/html/automake/2007-03/msg00001.html

> If `make maintainer-clean', then the GNU Standards should be changed
> to reflect this.  The obvious disadvantage is that if the
> bootstrap&&configure does not finish, maintainer-clean is not usable.

If configure does not finish then no Makefile based target is usable.
Which may have been your point.  But I think it is safe to assume a
working system and in an working system configure will finish and
Makefile targets will be available.

Bob



Re: Shouldn't the definition of maintainer-clean be changed?

by Stepan Kasal :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message

Hello Bob,

On Sat, Mar 17, 2007 at 10:44:42AM -0600, Bob Proulx wrote:
> First off let me say that I was perfectly aware of the standards for
> make maintainer-clean when I posted my response to that message.
> There is no standard target to perform the desired operation.  That
> poster had a very particular set of needs.  My suggestion there did
> not in any way reflect a "standard" use of automake or use of the gnu
> standards.  It was a very targeted (ab)use of the tool.  I knew that.

I'm sorry that I accused you and Ralf that you misinterpret the
target; I was wrong in both cases.

In the course of the preceding year or two, whenever I heard about
mainatiner-clean, it was misinterpreted this way.
(That's why I reacted so hysterically when I saw your hint on the
automake list.)

I cannot agree that the need is "very particular".  Virtually every
projects' CVS build instructions start with point 1. "get a clean
checkout".  And if the build does not work, the user wants to get back
to that clean checkout.

I was afraid that if we let the rumour spread, this will soon become
the de-facto standard for half of the projects, and the name
"maintainer-clean" will no longer have any meaning.

So I wanted to see how do the standard makers feel about it.

> It would be good to have some improved functionality in this area.
> See also my posting asking for a clean target for generated source
> files.  [All it needs is someone to actually do the work. :-)]
>
>   http://lists.gnu.org/archive/html/automake/2007-03/msg00001.html

OK, so if want to do something about this, I should first implement
--clean, and then start recommending it as the right tool for the
purpose.


Finally, a minor clarification:
> > If `make maintainer-clean', then the GNU Standards should be changed
> > to reflect this.  The obvious disadvantage is that if the
> > bootstrap&&configure does not finish, maintainer-clean is not usable.
>
> If configure does not finish then no Makefile based target is usable.
> Which may have been your point.  But I think it is safe to assume a
> working system and in an working system configure will finish and
> Makefile targets will be available.

It is common that a configure script ends with an error message that
``package foo is needed to build this project''.

(Yes, these configure scripts are badly written, as the AC_MSG_ERROR
is meant to notify about ``an error that prevents `configure' from
completing,'' as the manual says.  Yet is is often used in situations
which prevent the build from completing.)

So, in practice, one has to collect all of the pre-requisites of the
projects, before a working Makefile is available.

Thanks,
        Stepan Kasal



Re: Shouldn't the definition of maintainer-clean be changed?

by Benoit Sigoure :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message

Quoting Stepan Kasal <kasal@...>:
>
> In the course of the preceding year or two, whenever I heard about
> mainatiner-clean, it was misinterpreted this way.
> (That's why I reacted so hysterically when I saw your hint on the
> automake list.)

Same thing here. Actually I discovered last year, by reading the GNU Coding
Standards that maintainer-clean wasn't what I thought it was. Many
people still
get it wrong where I work.

>
> I cannot agree that the need is "very particular".  Virtually every
> projects' CVS build instructions start with point 1. "get a clean
> checkout".  And if the build does not work, the user wants to get back
> to that clean checkout.

Yes, I've frequently seen this too.

>
> I was afraid that if we let the rumour spread, this will soon become
> the de-facto standard for half of the projects, and the name
> "maintainer-clean" will no longer have any meaning.

I'm afraid that many people already use this target to un-bootstrap their
project by extending MAINTERCLEANFILES.

>
> So I wanted to see how do the standard makers feel about it.
>
>> It would be good to have some improved functionality in this area.
>> See also my posting asking for a clean target for generated source
>> files.  [All it needs is someone to actually do the work. :-)]
>>
>>   http://lists.gnu.org/archive/html/automake/2007-03/msg00001.html
>
> OK, so if want to do something about this, I should first implement
> --clean, and then start recommending it as the right tool for the
> purpose.
>

I started to implement --clean yesterday (from CVS HEAD)... It's the
very first
time I dig into the code of the autotools but it does not seem to be very hard
to implement. I don't know if I'll succeed but at least I can try ;)

In a first time, I'm trying to implement --clean in
autoreconf/aclocal/autoconf/autoheader/automake (maybe in autopoint too? I've
discovered this tool yesterday when reading the code of autoreconf)

Then I'm thinking of implementing a target such as "bootclean" that would do
maintainer-clean + un-bootstrap.

Any comments?

Cheers,

--
SIGOURE Benoit aka Tsuna
   _____
  /EPITA\ Promo 2008, LRDE




Re: Shouldn't the definition of maintainer-clean be changed?

by Ralf Wildenhues :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message

Hello everyone,

First, please be aware of another thread discussing a similar topic:
<http://thread.gmane.org/gmane.comp.lib.gnulib.bugs/9692/focus=9695>

* Benoit Sigoure wrote on Mon, Mar 19, 2007 at 12:39:32PM CET:
>
> Same thing here. Actually I discovered last year, by reading the GNU Coding
> Standards that maintainer-clean wasn't what I thought it was. Many
> people still get it wrong where I work.

There are a couple of decisions to make for implementation (and also for
eventual standardization, but let's just ignore this aspect for the
moment):

- It was already noted that the current way "maintainer-clean" works,
  is helpful for some people and needed by them.
  So don't destroy this for them.  Thus, use a new name for a new
  semantics.  This also helps other surprises due to backward
  incompatibility.

- If you think the "maintainer-clean" is the best possible name.
  Well, so someone chose less than ideally last time.  This should
  give you the more motivation to choose a good name this time.

> >I was afraid that if we let the rumour spread, this will soon become
> >the de-facto standard for half of the projects, and the name
> >"maintainer-clean" will no longer have any meaning.
>
> I'm afraid that many people already use this target to un-bootstrap their
> project by extending MAINTERCLEANFILES.

So?  The impact of doing so is mostly limited to the people developing
the package.  Few mere users of a package need the maintainer-clean
functionality very badly.  But if you change Automake, you will impact
all packages, also those that needed otherwise.

> In a first time, I'm trying to implement --clean in
> autoreconf/aclocal/autoconf/autoheader/automake (maybe in autopoint too?
> I've discovered this tool yesterday when reading the code of
> autoreconf)

Again, please look at the gnulib thread, and avoid doing work twice.
Thanks.

> Then I'm thinking of implementing a target such as "bootclean" that
> would do maintainer-clean + un-bootstrap.

The "bootstrap" name is another thing open to discussion.  FWIW, I don't
care enough, but at least for the autotools packages themselves, the
name makes sense: they do solve some kind of chicken and egg problem.

Hope that helps.

Cheers,
Ralf



Re: Shouldn't the definition of maintainer-clean be changed?

by jumbledletterstofoolname :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message


Hi Ralf,

I've followed some of this thread.  From my perspective:

* I'm okay what whatever is decided, as long as "maintainer-clean"
  semantics do not change.  New semantics -> new name, just like
  the way any other interface change should work

* I don't particularly care for the "autogen.sh" name for a boot-
  strap script.  GNOME adopted the name after I suggested using
  my tool for some repetitive tasks.

* if you are going to add new names, then the inverse of a
  "foo" step should likely be named "foo-clean", pre-existing
  tradition excepted.

* since running a bootstrap script is not part of the make process,
  it seems less than obvious to me that a make target should
  undo the bootstrap.

* How about having autoreconf (aka "bootstrap") take an option:

     autoreconf --clean
     bootstrap --clean

  I have my own script that traverses the hierarchy and removes any
  file or directory not under version control.  That's pretty
  effective for me.  :)

Regards - Bruce



Re: Shouldn't the definition of maintainer-clean be changed?

by Stepan Kasal :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message

Hello Bruce and all.

[Omitting autogen-users, I'll send a patch submission there
in a separate mail.]

  I started this thread with an unfortunate mail.  Allow me to
my current understanding of situation.

On Mon, Mar 19, 2007 at 10:00:05AM -0700, Bruce Korb wrote:
> [...] "maintainer-clean" semantics do not change. [...]

Yes, that was the main answer I got from the list.  The definition of
"maintainer-clean" should not change.

My mail sounded that I'm in favor of changing the definition.
Actually, I was under the impression that no one takes the definition
seriously, so I was trying to ask:  1) "Is this meant seriously?"
2) "If yes, how are we going to defend it?"

Though I failed to formulate the questions properly, I think I got my
answers:
1) Yes, and it is used in practice.
2) By implementing "auto* --clean" which would match people's need
   for "un-bootstrap".

> * How about having autoreconf (aka "bootstrap") take an option:
>      autoreconf --clean
>      bootstrap --clean

As said above, I gather that this is the way to go.

Have a nice day,  Stepan Kasal



Re: Shouldn't the definition of maintainer-clean be changed?

by Benoit Sigoure :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message

Quoting Ralf Wildenhues <Ralf.Wildenhues@...>:

> Hello everyone,
>
> First, please be aware of another thread discussing a similar topic:
> <http://thread.gmane.org/gmane.comp.lib.gnulib.bugs/9692/focus=9695>
>
> * Benoit Sigoure wrote on Mon, Mar 19, 2007 at 12:39:32PM CET:
>> In a first time, I'm trying to implement --clean in
>> autoreconf/aclocal/autoconf/autoheader/automake (maybe in autopoint too?
>> I've discovered this tool yesterday when reading the code of
>> autoreconf)
>
> Again, please look at the gnulib thread, and avoid doing work twice.
> Thanks.
>
>> Then I'm thinking of implementing a target such as "bootclean" that
>> would do maintainer-clean + un-bootstrap.
>
> The "bootstrap" name is another thing open to discussion.  FWIW, I don't
> care enough, but at least for the autotools packages themselves, the
> name makes sense: they do solve some kind of chicken and egg problem.
>
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 <project>-patches mailing
lists since it isn't something that will be applied but really a simple
proposal. Since it's the first time I actually hack these things,
comments from
code reviewers are welcome.

There is more work to be done: filling ChangeLog/NEWS entries,
documenting this
in manuals, supporting autopoint and maybe some other auto<stuff> I might have
omitted, and most important I think: adding tests (new feature = new bugs =>
new tests).

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.

Cheers,

--
SIGOURE Benoit aka Tsuna
   _____
  /EPITA\ Promo 2008, LRDE

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 -0000 1.24
+++ autoconf/bin/autoconf.as 19 Mar 2007 21:04:17 -0000
@@ -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
   -o, --output=FILE         save output in FILE (stdout is the default)
   -W, --warnings=CATEGORY   report the warnings falling in CATEGORY [syntax]
 
@@ -82,6 +83,7 @@
 autom4te_options=
 outfile=
 verbose=false
+clean=false
 
 # Parse command line.
 while test $# -gt 0 ; do
@@ -99,6 +101,9 @@
        verbose=:
        autom4te_options="$autom4te_options $1"; shift ;;
 
+    --clean )
+       clean=:; shift ;;
+
     # Arguments passed as is to autom4te.
     --debug      | -d   | \
     --force      | -f   | \
@@ -175,6 +180,10 @@
 # Unless specified, the output is stdout.
 test -z "$outfile" && outfile=-
 
+if $clean && test x"$outfile" != x-; then
+  exec rm -f "$outfile"
+fi
+
 # Run autom4te with expansion.
 eval set x $autom4te_options \
   --language=autoconf --output=\$outfile "$traces" \$infile
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.in 4 Jan 2007 16:43:06 -0000 1.147
+++ autoconf/bin/autoheader.in 19 Mar 2007 21:04:17 -0000
@@ -70,6 +70,7 @@
   -h, --help               print this help, then exit
   -V, --version            print version number, then exit
   -v, --verbose            verbosely report processing
+      --clean              remove the files that would otherwise be created
   -d, --debug              don\'t remove temporary files
   -f, --force              consider all files obsolete
   -W, --warnings=CATEGORY  report the warnings falling in CATEGORY
@@ -195,6 +196,13 @@
 ($config_h, $config_h_in) = split (':', $config_h, 2);
 $config_h_in ||= "$config_h.in";
 
+if ($clean)
+  {
+    unlink $config_h_in or error "error: Cannot remove `$config_h_in': $!"
+      unless not -f $config_h_in;
+    exit 0;
+  }
+
 # %SYMBOL might contain things like `F77_FUNC(name,NAME)', but we keep
 # only the name of the macro.
 %symbol = map { s/\(.*//; $_ => 1 } keys %symbol;
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.in 4 Jan 2007 16:43:06 -0000 1.137
+++ autoconf/bin/autoreconf.in 19 Mar 2007 21:04:17 -0000
@@ -74,6 +74,7 @@
   -d, --debug              don't remove temporary files
   -f, --force              consider all files obsolete
   -i, --install            copy missing auxiliary files
+  -c, --clean              remove auxiliary files
       --no-recursive       don't rebuild sub-packages
   -s, --symlink            with -i, install symbolic links instead of copies
   -m, --make               when applicable, re-run ./configure && make
@@ -150,10 +151,15 @@
   'I|include=s'          => \@include,
   'B|prepend-include=s' => \@prepend_include,
   'i|install'            => \$install,
+  # --clean is already handled by getopt, accept a short version:
+  'c'                    => \$clean,
   's|symlink'            => \$symlink,
   'm|make'               => \$make,
   'recursive!'           => \$recursive);
 
+  error "Cannot install and clean at the same time."
+    if ($install && $clean);
+
   # Split the warnings as a list of elements instead of a list of
   # lists.
   @warning = map { split /,/ } @warning;
@@ -196,6 +202,15 @@
       $automake   .= ' --copy' unless $symlink;
       $libtoolize .= ' --copy' unless $symlink;
     }
+  elsif ($clean)
+    {
+      # Don't tell autoconf and aclocal to --clean: we need them to do their
+      # work before we can actually remove their files.
+      $autoheader .= ' --clean';
+      $automake   .= ' --clean';
+      $autopoint  .= ' --clean';
+      $libtoolize .= ' --clean';
+    }
   # --force;
   if ($force)
     {
@@ -304,12 +319,50 @@
     }
 }
 
+# &run_make ([TARGET])
+# ------------
+# Run make in the current directory.  config.status is run first
+# in order to recreate the Makefile unless we're in --clean mode.
+# Return true on success, false if something went wrong.
+sub run_make (;$)
+{
+  my ($target) = @_;
+  $target = '' if not defined $target;
+
+  # Regenerate the Makefile first -- unless we're --clean mode.
+  if (!$clean)
+    {
+      if (!-f 'config.status')
+ {
+  verb 'no config.status: cannot re-make';
+  return 0;
+ }
+      else
+ {
+  xsystem ('./config.status --recheck');
+  xsystem ('./config.status');
+ }
+    }
+  if (!-f 'Makefile')
+    {
+      verb 'no Makefile: cannot re-make' unless $clean;
+      return 0;
+    }
+  else
+    {
+      xsystem ("make $target");
+    }
+  return 1;
+}
+
 # &autoreconf_current_directory
 # -----------------------------
 sub autoreconf_current_directory ()
 {
   my $configure_ac = find_configure_ac;
 
+  run_make ('maintainer-clean') if ($make && $clean);
+
   # ---------------------- #
   # Is it using Autoconf?  #
   # ---------------------- #
@@ -345,7 +398,7 @@
   # will fail: the Gettext macros are missing.
   #
   # Therefore, we can't use the traces to decide if we use Gettext or
-  # not.  I guess that once Gettext move to 2.5x we will be able to,
+  # not.  I guess that once Gettext moves to 2.5x we will be able to,
   # but in the meanwhile forget it.
   #
   # We can only grep for AM_GNU_GETTEXT_VERSION in configure.ac.  You
@@ -359,7 +412,7 @@
     {
       verb "$configure_ac: not using Gettext";
     }
-  elsif (!$install)
+  elsif (!$install && !$clean)
     {
       verb "$configure_ac: not running autopoint: --install not given";
     }
@@ -519,20 +572,21 @@
   # Running libtoolize.  #
   # -------------------- #
 
+  if ($uses_libltdl)
+    {
+      $libtoolize .= " --ltdl";
+    }
+
   if (!$uses_libtool)
     {
       verb "$configure_ac: not using Libtool";
     }
   elsif ($install)
     {
-      if ($uses_libltdl)
- {
-  $libtoolize .= " --ltdl";
- }
       xsystem ($libtoolize);
       $rerun_aclocal = 1;
     }
-  else
+  elsif (!$clean)
     {
       verb "$configure_ac: not running libtoolize: --install not given";
     }
@@ -569,6 +623,7 @@
   # latter runs the former, and (ii) autoconf is stricter than
   # autoheader.  So all in all, autoconf should give better error
   # messages.
+  $autoconf .= ' --clean' if $clean;
   xsystem ($autoconf);
 
 
@@ -588,7 +643,7 @@
     {
       verb "$configure_ac: not using Autoheader";
     }
-  else
+  elsif (!$clean)
     {
       xsystem ($autoheader);
     }
@@ -610,31 +665,23 @@
       xsystem ($automake);
     }
 
+  # ---------------------- #
+  # Finalize the cleanup.  #
+  # ---------------------- #
+
+  if ($clean)
+    {
+      run_aclocal ($aclocal, '--clean ' . $aclocal_flags);
+      xsystem ($libtoolize);
+      xsystem ($autoheader);
+    }
+
 
   # -------------- #
   # Running make.  #
   # -------------- #
 
-  if ($make)
-    {
-      if (!-f "config.status")
- {
-  verb "no config.status: cannot re-make";
- }
-      else
- {
-  xsystem ("./config.status --recheck");
-  xsystem ("./config.status");
-  if (!-f "Makefile")
-    {
-      verb "no Makefile: cannot re-make";
-    }
-  else
-    {
-      xsystem ("make");
-    }
- }
-    }
+  run_make () if ($make);
 }
 
 
Index: autoconf/lib/Autom4te/General.pm
===================================================================
RCS file: /sources/autoconf/autoconf/lib/Autom4te/General.pm,v
retrieving revision 1.37
diff -u -r1.37 General.pm
--- autoconf/lib/Autom4te/General.pm 25 Aug 2006 21:21:19 -0000 1.37
+++ autoconf/lib/Autom4te/General.pm 19 Mar 2007 21:04:19 -0000
@@ -1,5 +1,6 @@
 # autoconf -- create `configure' using m4 macros
-# Copyright (C) 2001, 2002, 2003, 2004, 2006 Free Software Foundation, Inc.
+# Copyright (C) 2001, 2002, 2003, 2004, 2006, 2007  Free Software
+# Foundation, Inc.
 
 # This program is free software; you can redistribute it and/or modify
 # it under the terms of the GNU General Public License as published by
@@ -50,7 +51,7 @@
 
 # Variables we define and export.
 my @export_vars =
-  qw ($debug $force $help $me $tmp $verbose $version);
+  qw ($debug $force $clean $help $me $tmp $verbose $version);
 
 # Functions we define and export.
 my @export_subs =
@@ -94,6 +95,16 @@
 use vars qw ($force);
 $force = undef;
 
+=item C<$clean>
+
+Set this variable to 1 to remove all files that would otherwise be
+created.
+
+=cut
+
+use vars qw ($clean);
+$clean = undef;
+
 =item C<$help>
 
 Set to the help message associated to the option C<--help>.
@@ -261,6 +272,7 @@
      "v|verbose"  => sub { ++$verbose },
      "d|debug"    => sub { ++$debug },
      'f|force'    => \$force,
+     'clean'      => \$clean,
 
      # User options last, so that they have precedence.
      %option);

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 -0000 1.140
+++ automake/aclocal.in 19 Mar 2007 21:04:23 -0000
@@ -8,7 +8,7 @@
 # aclocal - create aclocal.m4 by scanning configure.ac
 
 # Copyright (C) 1996, 1997, 1998, 1999, 2000, 2001, 2002, 2003, 2004,
-# 2005, 2006  Free Software Foundation, Inc.
+# 2005, 2006, 2007  Free Software Foundation, Inc.
 
 # This program is free software; you can redistribute it and/or modify
 # it under the terms of the GNU General Public License as published by
@@ -77,6 +77,12 @@
 # Option --force.
 my $force_output = 0;
 
+# Option --clean.
+my $clean = 0;
+
+# Files to remove with --clean.
+my @files_installed;
+
 # Modification time of the youngest dependency.
 my $greatest_mtime = 0;
 
@@ -248,6 +254,11 @@
     if $res;
   unlink_tmp;
  }
+      elsif ($clean)
+ {
+  # Remember that we must remove this file once we're finished.
+  push (@files_installed, $dest);
+ }
       elsif (!$dry_run)
  {
   xsystem ('cp', $src, $dest);
@@ -773,6 +784,14 @@
       return 0;
     }
 
+  # We are now about to output `$output_file'.  If we're in clean mode, we
+  # shall just stop here.
+  if ($clean)
+    {
+      push (@files_installed, $output_file);
+      return 1;
+    }
+
   # Nothing to output?!
   # FIXME: Shouldn't we diagnose this?
   return 1 if ! length ($output);
@@ -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
       --help                print this help, then exit
   -I DIR                    add directory to search list for .m4 files
       --install             copy third-party files to the first -I directory
@@ -915,6 +935,7 @@
      'diff:s' => \$diff_command,
      'dry-run' => \$dry_run,
      'force' => \$force_output,
+     'clean' => \$clean,
      'I=s' => \@user_includes,
      'install'          => \$install,
      'output=s' => \$output_file,
@@ -986,6 +1007,11 @@
       $dry_run = 1;
     }
 
+  if ($clean && $install)
+    {
+      fatal "Cannot install and clean at the same time.";
+    }
+
   if ($install && !@user_includes)
     {
       fatal ("--install should copy macros in the directory indicated by the"
@@ -1050,7 +1076,16 @@
     last if write_aclocal ($output_file, keys %macro_traced);
     last if $dry_run;
   }
-check_acinclude;
+check_acinclude unless $clean;
+
+if ($clean)
+  {
+    foreach my $cleanfile (@files_installed)
+      {
+ unlink $cleanfile or fatal "Failed to remove `$cleanfile': $!"
+  unless not -e $cleanfile;
+      }
+  }
 
 exit $exit_code;
 
Index: automake/automake.in
===================================================================
RCS file: /sources/automake/automake/automake.in,v
retrieving revision 1.1641
diff -u -r1.1641 automake.in
--- automake/automake.in 16 Oct 2006 05:24:17 -0000 1.1641
+++ automake/automake.in 19 Mar 2007 21:04:25 -0000
@@ -7,7 +7,7 @@
 
 # automake - create Makefile.in from Makefile.am
 # Copyright (C) 1994, 1995, 1996, 1997, 1998, 1999, 2000, 2001, 2002,
-# 2003, 2004, 2005, 2006  Free Software Foundation, Inc.
+# 2003, 2004, 2005, 2006, 2007  Free Software Foundation, Inc.
 
 # This program is free software; you can redistribute it and/or modify
 # it under the terms of the GNU General Public License as published by
@@ -291,6 +291,12 @@
 # TRUE if we should copy missing files; otherwise symlink if possible.
 my $copy_missing = 0;
 
+# TRUE if we shoud remove files that would otherwise be installed (--clean).
+my $clean = 0;
+
+# List of files to be removed when we're finished (--clean).
+my @files_installed;
+
 # TRUE if we should always update files that we know about.
 my $force_missing = 0;
 
@@ -7062,7 +7068,7 @@
       # The default auxiliary directory is the first
       # of ., .., or ../.. that contains install-sh.
       # Assume . if install-sh doesn't exist yet.
-      for my $dir (qw (. .. ../..))
+      for my $dir (qw(. .. ../..))
  {
   if (-f "$dir/install-sh")
     {
@@ -7290,6 +7296,7 @@
     $macro = rvar ($macro) unless ref $macro;
     if ($config_libobj_dir)
       {
+ # FIXME: Do we need to put @files in @files_installed when --clean?
  require_file_internal ($macro->rdef ($cond)->location, $mystrict,
        $config_libobj_dir, @files);
       }
@@ -7306,6 +7313,7 @@
 {
     my ($where, $mystrict, @files) = @_;
     require_file_internal ($where, $mystrict, $config_aux_dir, @files);
+    push (@files_installed, map { $_ = $config_aux_dir . '/' . $_ } @files);
 }
 
 
@@ -7526,10 +7534,17 @@
   # defined or overridden variables.
   $output_vars .= output_variables;
 
-  check_typos;
-
   my ($out_file) = $output_directory . '/' . $makefile_in;
 
+  if ($clean && -e $out_file)
+    {
+      unlink ($out_file)
+ or fatal "cannot remove $out_file: $!\n";
+      return;
+    }
+
+  check_typos;
+
   if ($exit_code != 0)
     {
       verb "not writing $out_file because of earlier errors";
@@ -7599,6 +7614,7 @@
       --version            print version number, then exit
   -v, --verbose            verbosely list files processed
       --no-force           only update Makefile.in's that are out of date
+      --clean              remove files that would otherwise be created
   -W, --warnings=CATEGORY  report the warnings falling in CATEGORY
 
 Dependency tracking:
@@ -7715,6 +7731,7 @@
      'o|output-dir=s' => \$output_directory,
      'a|add-missing' => \$add_missing,
      'c|copy'        => \$copy_missing,
+     'clean'        => \$clean,
      'v|verbose' => sub { setup_channel 'verb', silent => 0; },
      'W|warnings=s'     => \&parse_warnings,
      # These long options (--Werror and --Wno-error) for backward
@@ -7854,6 +7871,15 @@
       }
   }
 
+if ($clean)
+  {
+    foreach my $cleanfile (@files_installed)
+      {
+ unlink $cleanfile or fatal "Failed to remove `$cleanfile': $!"
+  unless not -e $cleanfile;
+      }
+  }
+
 exit $exit_code;
 
 

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 -0000 1.60
+++ libtool/libtoolize.m4sh 19 Mar 2007 21:04:29 -0000
@@ -5,7 +5,7 @@
 # libtoolize (GNU @PACKAGE@@TIMESTAMP@) @VERSION@
 # Written by Gary V. Vaughan <gary@...>, 2003
 
-# Copyright (C) 2003, 2004, 2005, 2006 Free Software Foundation, Inc.
+# Copyright (C) 2003, 2004, 2005, 2006, 2007 Free Software Foundation, Inc.
 # This is free software; see the source for copying conditions.  There is NO
 # warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
 
@@ -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
 #     --ltdl[=DIR]      install libltdl sources [default: libltdl]
 #     --nonrecursive    prepare ltdl for non-recursive make
 # -q, --quiet           work silently
@@ -89,6 +90,7 @@
 opt_debug=:
 opt_force=false
 opt_install=false
+opt_clean=false
 opt_link=:
 opt_ltdl=false
 
@@ -147,6 +149,10 @@
 
       --install|-i) opt_install=: ;;
 
+      --clean) opt_clean=:
+ opt_quiet=:
+ ;;
+
       --ltdl) opt_ltdl=:
        if test "$#" -gt 0; then
   case $1 in
@@ -729,6 +735,12 @@
     my_srcfile="$my_srcdir/$my_filename"
     my_destfile="$my_destdir/$my_filename"
 
+    if $opt_clean; then
+      rm -f "$my_destfile"
+      my_return_status=$?
+      return $?
+    fi
+
     test -f "$my_srcfile" || func_fatal_error "\`$my_srcfile' does not exist."
 
     if test -f "$my_destfile"; then
@@ -750,7 +762,6 @@
 
     if $my_serial_update_p || $opt_force; then
       func_copy "$my_srcfile" "$my_destfile"
-      my_return_status=$?
     elif test "X$my_dest_serial" = "X$my_src_serial"; then
       $opt_quiet \
         || func_echo "\`$my_destfile' is already up to date."
@@ -798,6 +809,12 @@
     my_srcfile="$my_srcdir/$my_filename"
     my_destfile="$my_destdir/$my_filename"
 
+    if $opt_clean; then
+      rm -f "$my_destfile"
+      my_return_status=$?
+      return $my_return_status
+    fi
+
     my_keyword_update_p=:
 
     test -f "$my_srcfile" || func_fatal_error "\`$my_srcfile' does not exist."

Re: Shouldn't the definition of maintainer-clean be changed?

by jumbledletterstofoolname :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message

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 -0000 1.24
> +++ autoconf/bin/autoconf.as 19 Mar 2007 21:04:17 -0000
> @@ -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.in 4 Jan 2007 16:43:06 -0000 1.147
> +++ autoconf/bin/autoheader.in 19 Mar 2007 21:04:17 -0000
> @@ -70,6 +70,7 @@
>    -h, --help               print this help, then exit
>    -V, --version            print version number, then exit
>    -v, --verbose            verbosely 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.in 4 Jan 2007 16:43:06 -0000 1.137
> +++ autoconf/bin/autoreconf.in 19 Mar 2007 21:04:17 -0000
> @@ -74,6 +74,7 @@
>    -d, --debug              don't remove temporary files
>    -f, --force              consider all files obsolete
>    -i, --install            copy 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 -0000 1.140
> +++ automake/aclocal.in 19 Mar 2007 21:04:23 -0000

> @@ -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 -0000 1.60
> +++ libtool/libtoolize.m4sh 19 Mar 2007 21:04:29 -0000
> @@ -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



Re: Shouldn't the definition of maintainer-clean be changed?

by Benoit Sigoure :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message

Quoting Bruce Korb <bkorb@...>:

> 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




Re: Shouldn't the definition of maintainer-clean be changed?

by jumbledletterstofoolname :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message

Benoit Sigoure wrote:

> Quoting Bruce Korb <bkorb@...>:
>
>> 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