| Message ID | 1453134445-31356-1-git-send-email-andrew.cooper3@citrix.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
>>> On 18.01.16 at 17:27, <andrew.cooper3@citrix.com> wrote: > * Move '*~' and 'core' into the find rule. I don't understand this part: Where in the build process do such get generated? I'm tempted to instead recommend to just drop those from the rm invocation... > * Remove 'System.map' along with the other primary targets > * Remove include/config/ and include/generated/ on clean > * Remove .config.old in distclean Everything else if fine with me. Jan
On 18/01/16 16:41, Jan Beulich wrote: >>>> On 18.01.16 at 17:27, <andrew.cooper3@citrix.com> wrote: >> * Move '*~' and 'core' into the find rule. > I don't understand this part: Where in the build process do such get > generated? I'm tempted to instead recommend to just drop those > from the rm invocation... No idea about 'core' files, but *~ are emacs backup files. Most clean rules do "rm *.o *.d *~ core" in the local directory, but there are some directories in the the public header area which don't get recursed into, and therefore missed. ~Andrew
>>> On 18.01.16 at 17:45, <andrew.cooper3@citrix.com> wrote: > On 18/01/16 16:41, Jan Beulich wrote: >>>>> On 18.01.16 at 17:27, <andrew.cooper3@citrix.com> wrote: >>> * Move '*~' and 'core' into the find rule. >> I don't understand this part: Where in the build process do such get >> generated? I'm tempted to instead recommend to just drop those >> from the rm invocation... > > No idea about 'core' files, but *~ are emacs backup files. But emacs should clean up after itself; this shouldn't be the job of our clean rule. > Most clean rules do "rm *.o *.d *~ core" in the local directory, but > there are some directories in the the public header area which don't get > recursed into, and therefore missed. Well - the same holds here than: I'd rather remove those than extend the bogus use. Jan
On 18/01/16 16:57, Jan Beulich wrote: >>>> On 18.01.16 at 17:45, <andrew.cooper3@citrix.com> wrote: >> On 18/01/16 16:41, Jan Beulich wrote: >>>>>> On 18.01.16 at 17:27, <andrew.cooper3@citrix.com> wrote: >>>> * Move '*~' and 'core' into the find rule. >>> I don't understand this part: Where in the build process do such get >>> generated? I'm tempted to instead recommend to just drop those >>> from the rm invocation... >> No idea about 'core' files, but *~ are emacs backup files. > But emacs should clean up after itself; this shouldn't be the job > of our clean rule. Why? the point is to have a one-revision old version of the file to hand. > >> Most clean rules do "rm *.o *.d *~ core" in the local directory, but >> there are some directories in the the public header area which don't get >> recursed into, and therefore missed. > Well - the same holds here than: I'd rather remove those than > extend the bogus use. Bogus is a matter of opinion, and there are a lot of emacs users (myself included) who will disagree with you here. ~Andrew
>>> On 18.01.16 at 19:19, <andrew.cooper3@citrix.com> wrote: > On 18/01/16 16:57, Jan Beulich wrote: >>>>> On 18.01.16 at 17:45, <andrew.cooper3@citrix.com> wrote: >>> On 18/01/16 16:41, Jan Beulich wrote: >>>>>>> On 18.01.16 at 17:27, <andrew.cooper3@citrix.com> wrote: >>>>> * Move '*~' and 'core' into the find rule. >>>> I don't understand this part: Where in the build process do such get >>>> generated? I'm tempted to instead recommend to just drop those >>>> from the rm invocation... >>> No idea about 'core' files, but *~ are emacs backup files. >> But emacs should clean up after itself; this shouldn't be the job >> of our clean rule. > > Why? the point is to have a one-revision old version of the file to hand. I guess there may be different strategies here: My editor also creates such named files, but deletes them as the program gets shut down. I.e. the one-revision old backup exists as long as the program is running. I can see benefits from the alternative model, but still it shouldn't be our scripts to clean up such backups. After all - what if another program used another name patter for its backups? Would we go clean those up then too? Jan
On Tue, 2016-01-19 at 01:43 -0700, Jan Beulich wrote: > > > > On 18.01.16 at 19:19, <andrew.cooper3@citrix.com> wrote: > > On 18/01/16 16:57, Jan Beulich wrote: > > > > > > On 18.01.16 at 17:45, <andrew.cooper3@citrix.com> wrote: > > > > On 18/01/16 16:41, Jan Beulich wrote: > > > > > > > > On 18.01.16 at 17:27, <andrew.cooper3@citrix.com> wrote: > > > > > > * Move '*~' and 'core' into the find rule. > > > > > I don't understand this part: Where in the build process do such > > > > > get > > > > > generated? I'm tempted to instead recommend to just drop those > > > > > from the rm invocation... > > > > No idea about 'core' files, but *~ are emacs backup files. > > > But emacs should clean up after itself; this shouldn't be the job > > > of our clean rule. > > > > Why? the point is to have a one-revision old version of the file to > > hand. > > I guess there may be different strategies here: My editor also > creates such named files, but deletes them as the program gets > shut down. I.e. the one-revision old backup exists as long as the > program is running. I can see benefits from the alternative > model, but still it shouldn't be our scripts to clean up such backups. > After all - what if another program used another name patter for > its backups? Would we go clean those up then too? IMHO these files should be in .gitignore (so they don't clutter "git status", AFAICT this is already done correctly) but it's not really necessary for "make clean" (or distclean) to get rid of them, that's up to either the editor or the user. IOW I'd be happy removing the existing rules. Removing "core" is even odder -- it implies people have been running segfaulting binaries directory out of the source tree, which is a little odd for tools/* but very odd for xen/*. I suppose one could argue that if some host binary run by the build system segfaults (and causes a build failure) that make clean ought to clean it up, that's a very edge case IMHO and, if arguing for doing it at all, would argue either for only doing "rm core" in directories which have such host build tools or doing it in a central/common location, but not spread around every subdirectory on the off chance there might be such a segfaulting binary in the future. > > Jan > > > > _______________________________________________ > Xen-devel mailing list > Xen-devel@lists.xen.org > http://lists.xen.org/xen-devel
On 19/01/16 10:38, Ian Campbell wrote: > On Tue, 2016-01-19 at 01:43 -0700, Jan Beulich wrote: >>>>> On 18.01.16 at 19:19, <andrew.cooper3@citrix.com> wrote: >>> On 18/01/16 16:57, Jan Beulich wrote: >>>>>>> On 18.01.16 at 17:45, <andrew.cooper3@citrix.com> wrote: >>>>> On 18/01/16 16:41, Jan Beulich wrote: >>>>>>>>> On 18.01.16 at 17:27, <andrew.cooper3@citrix.com> wrote: >>>>>>> * Move '*~' and 'core' into the find rule. >>>>>> I don't understand this part: Where in the build process do such >>>>>> get >>>>>> generated? I'm tempted to instead recommend to just drop those >>>>>> from the rm invocation... >>>>> No idea about 'core' files, but *~ are emacs backup files. >>>> But emacs should clean up after itself; this shouldn't be the job >>>> of our clean rule. >>> >>> Why? the point is to have a one-revision old version of the file to >>> hand. >> >> I guess there may be different strategies here: My editor also >> creates such named files, but deletes them as the program gets >> shut down. I.e. the one-revision old backup exists as long as the >> program is running. I can see benefits from the alternative >> model, but still it shouldn't be our scripts to clean up such backups. >> After all - what if another program used another name patter for >> its backups? Would we go clean those up then too? > > IMHO these files should be in .gitignore (so they don't clutter "git > status", AFAICT this is already done correctly) but it's not really > necessary for "make clean" (or distclean) to get rid of them, that's up to > either the editor or the user. IOW I'd be happy removing the existing > rules. What about adding a "make gitclean" which will remove all files ignored by git? It could use .gitignore (or even "git clean -dffq"). This way "make [dist]clean" could be limited to the files created by the build process on purpose. Juergen
On Tue, 2016-01-19 at 11:06 +0100, Juergen Gross wrote: > On 19/01/16 10:38, Ian Campbell wrote: > > On Tue, 2016-01-19 at 01:43 -0700, Jan Beulich wrote: > > > > > > On 18.01.16 at 19:19, <andrew.cooper3@citrix.com> wrote: > > > > On 18/01/16 16:57, Jan Beulich wrote: > > > > > > > > On 18.01.16 at 17:45, <andrew.cooper3@citrix.com> wrote: > > > > > > On 18/01/16 16:41, Jan Beulich wrote: > > > > > > > > > > On 18.01.16 at 17:27, <andrew.cooper3@citrix.com> > > > > > > > > > > wrote: > > > > > > > > * Move '*~' and 'core' into the find rule. > > > > > > > I don't understand this part: Where in the build process do > > > > > > > such > > > > > > > get > > > > > > > generated? I'm tempted to instead recommend to just drop > > > > > > > those > > > > > > > from the rm invocation... > > > > > > No idea about 'core' files, but *~ are emacs backup files. > > > > > But emacs should clean up after itself; this shouldn't be the job > > > > > of our clean rule. > > > > > > > > Why? the point is to have a one-revision old version of the file to > > > > hand. > > > > > > I guess there may be different strategies here: My editor also > > > creates such named files, but deletes them as the program gets > > > shut down. I.e. the one-revision old backup exists as long as the > > > program is running. I can see benefits from the alternative > > > model, but still it shouldn't be our scripts to clean up such > > > backups. > > > After all - what if another program used another name patter for > > > its backups? Would we go clean those up then too? > > > > IMHO these files should be in .gitignore (so they don't clutter "git > > status", AFAICT this is already done correctly) but it's not really > > necessary for "make clean" (or distclean) to get rid of them, that's up > > to > > either the editor or the user. IOW I'd be happy removing the existing > > rules. > > What about adding a "make gitclean" which will remove all files ignored > by git? It could use .gitignore (or even "git clean -dffq"). This way > "make [dist]clean" could be limited to the files created by the build > process on purpose. IMHO people should just use "git clean" in whichever way suits them if this is they want. Ian.
On Tue, Jan 19, 2016 at 9:38 AM, Ian Campbell <ian.campbell@citrix.com> wrote: > On Tue, 2016-01-19 at 01:43 -0700, Jan Beulich wrote: >> > > > On 18.01.16 at 19:19, <andrew.cooper3@citrix.com> wrote: >> > On 18/01/16 16:57, Jan Beulich wrote: >> > > > > > On 18.01.16 at 17:45, <andrew.cooper3@citrix.com> wrote: >> > > > On 18/01/16 16:41, Jan Beulich wrote: >> > > > > > > > On 18.01.16 at 17:27, <andrew.cooper3@citrix.com> wrote: >> > > > > > * Move '*~' and 'core' into the find rule. >> > > > > I don't understand this part: Where in the build process do such >> > > > > get >> > > > > generated? I'm tempted to instead recommend to just drop those >> > > > > from the rm invocation... >> > > > No idea about 'core' files, but *~ are emacs backup files. >> > > But emacs should clean up after itself; this shouldn't be the job >> > > of our clean rule. >> > >> > Why? the point is to have a one-revision old version of the file to >> > hand. >> >> I guess there may be different strategies here: My editor also >> creates such named files, but deletes them as the program gets >> shut down. I.e. the one-revision old backup exists as long as the >> program is running. I can see benefits from the alternative >> model, but still it shouldn't be our scripts to clean up such backups. >> After all - what if another program used another name patter for >> its backups? Would we go clean those up then too? > > IMHO these files should be in .gitignore (so they don't clutter "git > status", AFAICT this is already done correctly) but it's not really > necessary for "make clean" (or distclean) to get rid of them, that's up to > either the editor or the user. IOW I'd be happy removing the existing > rules. As an emacs user, I agree with this. The purpose of "make clean" IMO is be to make sure that the *build* operates cleanly (i.e., doesn't end up using any output generated from a previous build), not to get rid of extraneous random files that don't affect the build. "git clean" is the proper tool for cleaning out the tree for git commands. -George
diff --git a/xen/Makefile b/xen/Makefile index 8b530c2..ff0d0d0 100644 --- a/xen/Makefile +++ b/xen/Makefile @@ -106,14 +106,15 @@ _clean: delete-unfresh-files $(MAKE) -f $(BASEDIR)/Rules.mk -C crypto clean $(MAKE) -f $(BASEDIR)/Rules.mk -C arch/$(TARGET_ARCH) clean $(MAKE) -f $(BASEDIR)/tools/kconfig/Makefile.kconfig ARCH=$(ARCH) SRCARCH=$(SRCARCH) clean - find . \( -name "*.o" -o -name ".*.d" \) -exec rm -f {} \; - rm -f include/asm $(TARGET) $(TARGET).gz $(TARGET).efi $(TARGET)-syms *~ core + find . \( -name "*.o" -o -name ".*.d" -o -name "*~" -o -name core \) -exec rm -f {} \; + rm -f include/asm $(TARGET) $(TARGET).gz $(TARGET).efi $(TARGET)-syms System.map rm -f include/asm-*/asm-offsets.h + rm -rf include/config/ include/generated/ rm -f .banner .PHONY: _distclean _distclean: clean - rm -f tags TAGS cscope.files cscope.in.out cscope.out cscope.po.out GTAGS GPATH GRTAGS GSYMS .config + rm -f tags TAGS cscope.files cscope.in.out cscope.out cscope.po.out GTAGS GPATH GRTAGS GSYMS .config .config.old $(TARGET).gz: $(TARGET) gzip -f -9 < $< > $@.new
* Move '*~' and 'core' into the find rule. * Remove 'System.map' along with the other primary targets * Remove include/config/ and include/generated/ on clean * Remove .config.old in distclean Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com> --- CC: Jan Beulich <JBeulich@suse.com> --- xen/Makefile | 7 ++++--- 1 file changed, 4 insertions(+), 3 deletions(-)