[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[bug #66085] second run of "make" requires user interaction
From: |
G. Branden Robinson |
Subject: |
[bug #66085] second run of "make" requires user interaction |
Date: |
Fri, 16 Aug 2024 08:15:48 -0400 (EDT) |
Follow-up Comment #4, bug #66085 (group groff):
[comment #2 comment #2:]
> I am not. I probably heard that at some point, but that probably wasn't a
point at which I was building groff regularly.
>
> I see this is in INSTALL.extra:
> 5. You can remove the groff executables and other generated files from
> the source code directory by typing 'make clean'. To also remove
> the files that 'configure' created (so you can compile groff for a
> different kind of computer or with different options to
> 'configure'), type 'make distclean'.
> ...a file I've never looked closely at because I've BUILT groff a few times
now but never tried to INSTALL it. (I prefer my installed groff to come from
my distro.) But only a fraction of the content of that file deals with
installing, so the filename is a bit misleading.
The use of a file named "INSTALL" in a source distribution is a familiar and
long-standing convention. I don't see it explicitly countenanced by the GNU
Coding Standards document, so I reckon we have some flexibility, but I don't
think we're necessarily going to be well served by renaming such files to
"BUILD" or dividing their contents between "BUILD" and "INSTALL" files.
Moreover, the "README" file explicitly steers people to "INSTALL.extra" and
"INSTALL.REPO", and "HACKING" explicitly steers people to "INSTALL.REPO"[1]
and "MANIFEST".
So I'm wondering if we really have a problem that more documentation can fix.
People might try consulting what's already there first...
[comment #3 comment #3:]
> But more conceptually, just by running "make," the user is agreeing to
overwrite any files that "make" makes. Asking for agreement to overwrite some
individual files is redundant.
This makes sense to me, but what you're observing are reconstructions of
gnulib files. We don't have a lot of control over that submodule's build
process (and frankly, we don't want that kind of control).
I'm inclined to defer to a gnulib expert. I won't be surprised if the answer
is "sorry, you've just gotta `distclean` before re-`configure`-ing."
[1] I see a capitalization error. Next push will fix.
_______________________________________________________
Reply to this item at:
<https://savannah.gnu.org/bugs/?66085>
_______________________________________________
Message sent via Savannah
https://savannah.gnu.org/
signature.asc
Description: PGP signature
- [bug #66085] second run of "make" requires user interaction, Dave, 2024/08/13
- [bug #66085] second run of "make" requires user interaction, G. Branden Robinson, 2024/08/15
- [bug #66085] second run of "make" requires user interaction, Dave, 2024/08/15
- [bug #66085] second run of "make" requires user interaction, Dave, 2024/08/16
- [bug #66085] second run of "make" requires user interaction,
G. Branden Robinson <=
- [bug #66085] second run of "make" requires user interaction, Dave, 2024/08/16
- [bug #66085] second run of "make" requires user interaction, Dave, 2024/08/17
- [bug #66085] second run of "make" requires user interaction, G. Branden Robinson, 2024/08/17
- [bug #66085] second run of "make" requires user interaction, Dave, 2024/08/17
- [bug #66085] second run of "make" requires user interaction, G. Branden Robinson, 2024/08/18
- [bug #66085] second run of "make" requires user interaction, G. Branden Robinson, 2024/08/31