GNU bug report logs - #32074
maintainer-clean and removing configure/Makefile.in/etc.

Previous Next

Package: automake;

Reported by: Karl Berry <karl <at> freefriends.org>

Date: Fri, 6 Jul 2018 23:29:01 UTC

Severity: normal

Done: Mathieu Lirzin <mthl <at> gnu.org>

Bug is archived. No further changes may be made.

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 32074 in the body.
You can then email your comments to 32074 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

View this report as an mbox folder, status mbox, maintainer mbox


Report forwarded to bug-automake <at> gnu.org:
bug#32074; Package automake. (Fri, 06 Jul 2018 23:29:01 GMT) Full text and rfc822 format available.

Acknowledgement sent to Karl Berry <karl <at> freefriends.org>:
New bug report received and forwarded. Copy sent to bug-automake <at> gnu.org. (Fri, 06 Jul 2018 23:29:01 GMT) Full text and rfc822 format available.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Karl Berry <karl <at> freefriends.org>
To: bug-automake <at> gnu.org
Subject: maintainer-clean and removing configure/Makefile.in/etc.
Date: Fri, 6 Jul 2018 23:27:48 GMT
Hi - the automake manual has (for many years) said:

    @code{maintainer-clean} should not delete anything that needs to exist
    in order to run @samp{./configure && make}.
    @end itemize

    We recommend that you follow this same set of heuristics in your
    @file{Makefile.am}.

That heuristic made sense when Francois formulated it decades ago. But
nowadays, especially since autoreconf exists, it does not seem
unreasonable to me to want to delete Makefile.in, configure, etc. It is
just as easy to run autoreconf (or equivalent) as configure&&make, and
it feels nice to have such dependent files gone from the source tree,
especially when working on setting up a package with autotools.

I certainly don't suggest changing any behavior, but perhaps the manual
could mention that it could be done via maintainer-clean-local or
MAINTAINERCLEANFILES, e.g.:

MAINTAINERCLEANFILES = aclocal.m4 config.h.in configure \
                       Makefile Makefile.in */Makefile */Makefile.in

Some maintainers might prefer to also remove build-aux or more; personally
that's one step too much for me. All the more reason not to change any
code :).

Just an idea ... --best, karl.




Information forwarded to bug-automake <at> gnu.org:
bug#32074; Package automake. (Sat, 07 Jul 2018 00:29:01 GMT) Full text and rfc822 format available.

Message #8 received at 32074 <at> debbugs.gnu.org (full text, mbox):

From: Jack Kelly <jack <at> jackkelly.name>
To: Karl Berry <karl <at> freefriends.org>
Cc: 32074 <at> debbugs.gnu.org
Subject: Re: bug#32074: maintainer-clean and removing
 configure/Makefile.in/etc.
Date: Sat, 07 Jul 2018 10:28:15 +1000
Karl Berry <karl <at> freefriends.org> writes:

> [snip automake manual blockquote]
>
> But nowadays, especially since autoreconf exists, it does not seem
> unreasonable to me to want to delete Makefile.in, configure, etc. It
> is just as easy to run autoreconf (or equivalent) as configure&&make,
> and it feels nice to have such dependent files gone from the source
> tree, especially when working on setting up a package with autotools.
>
> I certainly don't suggest changing any behavior, but perhaps the manual
> could mention that it could be done via maintainer-clean-local or
> MAINTAINERCLEANFILES, e.g.:
>
> MAINTAINERCLEANFILES = aclocal.m4 config.h.in configure \
>                        Makefile Makefile.in */Makefile */Makefile.in
>
> Some maintainers might prefer to also remove build-aux or more...

It is certainly valuable to test that you can bootstrap your package
from autoreconf up, but I don't think `make maintainer-clean' is the
best place to do that. The `git-clean' command removes untracked files
from the worktree, and I'm sure other VCSes let you do similar
things. Maybe the manual could point to those commands?

-- Jack




Information forwarded to bug-automake <at> gnu.org:
bug#32074; Package automake. (Sat, 07 Jul 2018 09:55:02 GMT) Full text and rfc822 format available.

Message #11 received at 32074 <at> debbugs.gnu.org (full text, mbox):

From: Mathieu Lirzin <mthl <at> gnu.org>
To: Karl Berry <karl <at> freefriends.org>
Cc: 32074 <at> debbugs.gnu.org
Subject: Re: bug#32074: maintainer-clean and removing
 configure/Makefile.in/etc.
Date: Sat, 07 Jul 2018 11:53:48 +0200
Hello Karl,

Karl Berry <karl <at> freefriends.org> writes:

> Hi - the automake manual has (for many years) said:
>
>     @code{maintainer-clean} should not delete anything that needs to exist
>     in order to run @samp{./configure && make}.
>     @end itemize
>
>     We recommend that you follow this same set of heuristics in your
>     @file{Makefile.am}.
>
> That heuristic made sense when Francois formulated it decades ago. But
> nowadays, especially since autoreconf exists, it does not seem
> unreasonable to me to want to delete Makefile.in, configure, etc. It is
> just as easy to run autoreconf (or equivalent) as configure&&make, and
> it feels nice to have such dependent files gone from the source tree,
> especially when working on setting up a package with autotools.

What is not clear to me is the reasoning of that heuristic.  You seems
to suggest that it has been introduced to avoid having to know the order
in which autoconf, aclocal, automake, ... has to be run.  Have you any
reference regarding that?

I would guess that the reason is more that this command might be run
from a tarball and that if the package builder doesn't know that
Autotools is now needed as a dependency, that person is left without any
instruction regarding what to do.

> I certainly don't suggest changing any behavior, but perhaps the manual
> could mention that it could be done via maintainer-clean-local or
> MAINTAINERCLEANFILES, e.g.:
>
> MAINTAINERCLEANFILES = aclocal.m4 config.h.in configure \
>                        Makefile Makefile.in */Makefile */Makefile.in
>
> Some maintainers might prefer to also remove build-aux or more; personally
> that's one step too much for me. All the more reason not to change any
> code :).

Can you explain why this step would be too much for you?

Thanks.

-- 
Mathieu Lirzin
GPG: F2A3 8D7E EB2B 6640 5761  070D 0ADE E100 9460 4D37




Information forwarded to bug-automake <at> gnu.org:
bug#32074; Package automake. (Sat, 07 Jul 2018 10:10:01 GMT) Full text and rfc822 format available.

Message #14 received at 32074 <at> debbugs.gnu.org (full text, mbox):

From: Mathieu Lirzin <mthl <at> gnu.org>
To: Jack Kelly <jack <at> jackkelly.name>
Cc: 32074 <at> debbugs.gnu.org, Karl Berry <karl <at> freefriends.org>
Subject: Re: bug#32074: maintainer-clean and removing
 configure/Makefile.in/etc.
Date: Sat, 07 Jul 2018 12:08:51 +0200
Hello Jack,

Jack Kelly <jack <at> jackkelly.name> writes:

> Karl Berry <karl <at> freefriends.org> writes:
>
>> [snip automake manual blockquote]
>>
>> But nowadays, especially since autoreconf exists, it does not seem
>> unreasonable to me to want to delete Makefile.in, configure, etc. It
>> is just as easy to run autoreconf (or equivalent) as configure&&make,
>> and it feels nice to have such dependent files gone from the source
>> tree, especially when working on setting up a package with autotools.
>>
>> I certainly don't suggest changing any behavior, but perhaps the manual
>> could mention that it could be done via maintainer-clean-local or
>> MAINTAINERCLEANFILES, e.g.:
>>
>> MAINTAINERCLEANFILES = aclocal.m4 config.h.in configure \
>>                        Makefile Makefile.in */Makefile */Makefile.in
>>
>> Some maintainers might prefer to also remove build-aux or more...
>
> It is certainly valuable to test that you can bootstrap your package
> from autoreconf up, but I don't think `make maintainer-clean' is the
> best place to do that. The `git-clean' command removes untracked files
> from the worktree, and I'm sure other VCSes let you do similar
> things. Maybe the manual could point to those commands?

This works only when files generated by Autotools are not commited to
VCS.  Having said that, I agree this is a general good practice that
ought to be documented in Automake's manual.  Have you any suggestion
regarding the location and wording?

Thanks.

[1] https://www.gnu.org/software/automake/faq/gnulib.html#VCS-Issues

-- 
Mathieu Lirzin
GPG: F2A3 8D7E EB2B 6640 5761  070D 0ADE E100 9460 4D37




Information forwarded to bug-automake <at> gnu.org:
bug#32074; Package automake. (Sat, 07 Jul 2018 21:41:02 GMT) Full text and rfc822 format available.

Message #17 received at 32074 <at> debbugs.gnu.org (full text, mbox):

From: Karl Berry <karl <at> freefriends.org>
To: mthl <at> gnu.org
Cc: 32074 <at> debbugs.gnu.org
Subject: Re: bug#32074: maintainer-clean and removing
 configure/Makefile.in/etc.
Date: Sat, 7 Jul 2018 21:40:20 GMT
Hi Mathieu,

Thanks for the quick reply.

    What is not clear to me is the reasoning of that heuristic.  You seems
    to suggest that it has been introduced to avoid having to know the order
    in which autoconf, aclocal, automake, ... has to be run.  Have you any
    reference regarding that?

I've been looking through my old mail about this. I can't reconstruct
the whole trail, but this message from rms to me seems to be the crux of
the "don't delete configure" special case (this is the whole message and
I have no other direct context, but still).

  Date: Sat, 19 Sep 92 23:42:28 -0400
  From: rms <at> gnu.ai.mit.edu (Richard Stallman)
  To: karl <at> cs.umb.edu
  Subject: realclean: rm configure

  You can't reconstruct configure with the makefile
  if there is no configure.

That was true in 1992 (no autoreconf :), but is routinely not true
today.

Francois, Tom Tromey, Akim Demaille, Jim Meyering, I, and others were
going through many iterations of what should be deleted in which target
in those years. I can't pin down the exact source of that heuristic
though.

    I would guess that the reason is more that this command might be run
    from a tarball 

I don't see why that's an issue. If an installer runs maintainer-clean
after unpacking a tarball, they are responsible for their own actions.
That's why the target is named *maintainer*-clean :).
    
https://www.gnu.org/prep/standards/html_node/Standard-Targets.html
talks about this in explicit detail. (It also implies that Makefile.in
files should be deleted, by the way. Hmm.)

    and that if the package builder doesn't know that Autotools is now
    needed as a dependency, that person is left without any instruction

There are always instructions ...

    Can you explain why this step would be too much for you?

Because I might (and usually do) have newer versions of the common files
than what missing would copy (ie, updated since the last Automake
release). Regardless, if you want to put build-aux (or whatever) into
the example in the manual, I don't object.

Best,
Karl




Information forwarded to bug-automake <at> gnu.org:
bug#32074; Package automake. (Sat, 07 Jul 2018 22:31:01 GMT) Full text and rfc822 format available.

Message #20 received at 32074 <at> debbugs.gnu.org (full text, mbox):

From: Jack Kelly <jack <at> jackkelly.name>
To: Mathieu Lirzin <mthl <at> gnu.org>
Cc: 32074 <at> debbugs.gnu.org, Karl Berry <karl <at> freefriends.org>
Subject: Re: bug#32074: maintainer-clean and removing
 configure/Makefile.in/etc.
Date: Sun, 08 Jul 2018 08:29:57 +1000
Mathieu Lirzin <mthl <at> gnu.org> writes:

> Jack Kelly <jack <at> jackkelly.name> writes:
>
>> It is certainly valuable to test that you can bootstrap your package
>> from autoreconf up, but I don't think `make maintainer-clean' is the
>> best place to do that. The `git-clean' command removes untracked files
>> from the worktree, and I'm sure other VCSes let you do similar
>> things. Maybe the manual could point to those commands?
>
> This works only when files generated by Autotools are not commited to
> VCS.  Having said that, I agree this is a general good practice that
> ought to be documented in Automake's manual.  Have you any suggestion
> regarding the location and wording?

Possibly under the "What Gets Cleaned" section of the manual?

-- Jack




Information forwarded to bug-automake <at> gnu.org:
bug#32074; Package automake. (Sat, 07 Jul 2018 22:31:02 GMT) Full text and rfc822 format available.

Message #23 received at 32074 <at> debbugs.gnu.org (full text, mbox):

From: Mathieu Lirzin <mthl <at> gnu.org>
To: Karl Berry <karl <at> freefriends.org>
Cc: 32074 <at> debbugs.gnu.org
Subject: Re: bug#32074: maintainer-clean and removing
 configure/Makefile.in/etc.
Date: Sun, 08 Jul 2018 00:30:33 +0200
Karl Berry <karl <at> freefriends.org> writes:

>     What is not clear to me is the reasoning of that heuristic.  You seems
>     to suggest that it has been introduced to avoid having to know the order
>     in which autoconf, aclocal, automake, ... has to be run.  Have you any
>     reference regarding that?
>
> I've been looking through my old mail about this. I can't reconstruct
> the whole trail, but this message from rms to me seems to be the crux of
> the "don't delete configure" special case (this is the whole message and
> I have no other direct context, but still).
>
>   Date: Sat, 19 Sep 92 23:42:28 -0400
>   From: rms <at> gnu.ai.mit.edu (Richard Stallman)
>   To: karl <at> cs.umb.edu
>   Subject: realclean: rm configure
>
>   You can't reconstruct configure with the makefile
>   if there is no configure.
>
> That was true in 1992 (no autoreconf :), but is routinely not true
> today.
>
> Francois, Tom Tromey, Akim Demaille, Jim Meyering, I, and others were
> going through many iterations of what should be deleted in which target
> in those years. I can't pin down the exact source of that heuristic
> though.

Thanks for the context.

>     I would guess that the reason is more that this command might be run
>     from a tarball 
>
> I don't see why that's an issue. If an installer runs maintainer-clean
> after unpacking a tarball, they are responsible for their own actions.
> That's why the target is named *maintainer*-clean :).
>     
> https://www.gnu.org/prep/standards/html_node/Standard-Targets.html
> talks about this in explicit detail. (It also implies that Makefile.in
> files should be deleted, by the way. Hmm.)

“More generally, ‘make maintainer-clean’ should not delete anything that
needs to exist in order to run configure and then begin to build the
program”

This seems to imply that Makefile.in should be kept, no?

>     and that if the package builder doesn't know that Autotools is now
>     needed as a dependency, that person is left without any instruction
>
> There are always instructions ...

What I meant is that ‘./configure’ output can't help that use with an helpful
error anymore.  But as you pointed above this is the user responsability.

>     Can you explain why this step would be too much for you?
>
> Because I might (and usually do) have newer versions of the common files
> than what missing would copy (ie, updated since the last Automake
> release). Regardless, if you want to put build-aux (or whatever) into
> the example in the manual, I don't object.

Makes sense.  I just wanted to understand.  :-)

I think Automake shouldn't suggest something that is explicitly
discouraged by the GCS. After reading the GCS link you gave, the
suggestion of adding “configure” and other files to MAINTAINERCLEANFILES
seems to contradict with it.

I am personnaly not against your suggestion as long as it matches the
GCS recommandation.  So I would suggest discussing it on
<bug-standards <at> gnu.org> or <gnu-prog-discuss <at> gnu.org> to see if others
agree that GCS is outdated in that regard before modifying the Automake
manual.  WDYT?

-- 
Mathieu Lirzin
GPG: F2A3 8D7E EB2B 6640 5761  070D 0ADE E100 9460 4D37




Information forwarded to bug-automake <at> gnu.org:
bug#32074; Package automake. (Sun, 08 Jul 2018 21:17:02 GMT) Full text and rfc822 format available.

Message #26 received at 32074 <at> debbugs.gnu.org (full text, mbox):

From: Karl Berry <karl <at> freefriends.org>
To: mthl <at> gnu.org
Cc: 32074 <at> debbugs.gnu.org
Subject: Re: bug#32074: maintainer-clean and removing
 configure/Makefile.in/etc.
Date: Sun, 8 Jul 2018 21:16:29 GMT
    I think Automake shouldn't suggest something that is explicitly
    discouraged by the GCS.

Good point. I agree.

    I would suggest discussing it on ...

Perfectly reasonable, but I'm just too old to have the stomach for those
discussions any more :(. Hardly the most crucial suggestion in the
world, fine for it to be relegated to the dustheap of history :).

--all the best,
karl




Information forwarded to bug-automake <at> gnu.org:
bug#32074; Package automake. (Sun, 08 Jul 2018 21:36:01 GMT) Full text and rfc822 format available.

Message #29 received at 32074 <at> debbugs.gnu.org (full text, mbox):

From: Mathieu Lirzin <mthl <at> gnu.org>
To: Karl Berry <karl <at> freefriends.org>
Cc: 32074 <at> debbugs.gnu.org
Subject: Re: bug#32074: maintainer-clean and removing
 configure/Makefile.in/etc.
Date: Sun, 08 Jul 2018 23:35:07 +0200
Karl Berry <karl <at> freefriends.org> writes:

>     I think Automake shouldn't suggest something that is explicitly
>     discouraged by the GCS.
>
> Good point. I agree.
>
>     I would suggest discussing it on ...
>
> Perfectly reasonable, but I'm just too old to have the stomach for those
> discussions any more :(. Hardly the most crucial suggestion in the
> world, fine for it to be relegated to the dustheap of history :).

No need to be old to be relunctant about starting this kind of
discussions which are often painful.  :-)

Feel free to reopen the bug if you change your mind.

-- 
Mathieu Lirzin
GPG: F2A3 8D7E EB2B 6640 5761  070D 0ADE E100 9460 4D37




bug closed, send any further explanations to 32074 <at> debbugs.gnu.org and Karl Berry <karl <at> freefriends.org> Request was from Mathieu Lirzin <mthl <at> gnu.org> to control <at> debbugs.gnu.org. (Sun, 08 Jul 2018 21:37:02 GMT) Full text and rfc822 format available.

bug archived. Request was from Debbugs Internal Request <help-debbugs <at> gnu.org> to internal_control <at> debbugs.gnu.org. (Mon, 06 Aug 2018 11:24:03 GMT) Full text and rfc822 format available.

This bug report was last modified 6 years and 312 days ago.

Previous Next


GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.