GNU bug report logs -
#32074
maintainer-clean and removing configure/Makefile.in/etc.
Previous Next
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.
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):
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):
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):
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):
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):
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):
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):
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):
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):
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.