* [PATCH] xen: Improvements to clean and distclean targets @ 2016-01-18 16:27 Andrew Cooper 2016-01-18 16:41 ` Jan Beulich 0 siblings, 1 reply; 10+ messages in thread From: Andrew Cooper @ 2016-01-18 16:27 UTC (permalink / raw) To: Xen-devel; +Cc: Andrew Cooper, Jan Beulich * 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(-) 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 -- 2.1.4 ^ permalink raw reply related [flat|nested] 10+ messages in thread
* Re: [PATCH] xen: Improvements to clean and distclean targets 2016-01-18 16:27 [PATCH] xen: Improvements to clean and distclean targets Andrew Cooper @ 2016-01-18 16:41 ` Jan Beulich 2016-01-18 16:45 ` Andrew Cooper 0 siblings, 1 reply; 10+ messages in thread From: Jan Beulich @ 2016-01-18 16:41 UTC (permalink / raw) To: Andrew Cooper; +Cc: Xen-devel >>> 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 ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [PATCH] xen: Improvements to clean and distclean targets 2016-01-18 16:41 ` Jan Beulich @ 2016-01-18 16:45 ` Andrew Cooper 2016-01-18 16:57 ` Jan Beulich 0 siblings, 1 reply; 10+ messages in thread From: Andrew Cooper @ 2016-01-18 16:45 UTC (permalink / raw) To: Jan Beulich; +Cc: Xen-devel 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 ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [PATCH] xen: Improvements to clean and distclean targets 2016-01-18 16:45 ` Andrew Cooper @ 2016-01-18 16:57 ` Jan Beulich 2016-01-18 18:19 ` Andrew Cooper 0 siblings, 1 reply; 10+ messages in thread From: Jan Beulich @ 2016-01-18 16:57 UTC (permalink / raw) To: Andrew Cooper; +Cc: Xen-devel >>> 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 ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [PATCH] xen: Improvements to clean and distclean targets 2016-01-18 16:57 ` Jan Beulich @ 2016-01-18 18:19 ` Andrew Cooper 2016-01-19 8:43 ` Jan Beulich 0 siblings, 1 reply; 10+ messages in thread From: Andrew Cooper @ 2016-01-18 18:19 UTC (permalink / raw) To: Jan Beulich; +Cc: Xen-devel 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 ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [PATCH] xen: Improvements to clean and distclean targets 2016-01-18 18:19 ` Andrew Cooper @ 2016-01-19 8:43 ` Jan Beulich 2016-01-19 9:38 ` Ian Campbell 0 siblings, 1 reply; 10+ messages in thread From: Jan Beulich @ 2016-01-19 8:43 UTC (permalink / raw) To: Andrew Cooper; +Cc: Xen-devel >>> 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 ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [PATCH] xen: Improvements to clean and distclean targets 2016-01-19 8:43 ` Jan Beulich @ 2016-01-19 9:38 ` Ian Campbell 2016-01-19 10:06 ` Juergen Gross 2016-01-20 10:22 ` George Dunlap 0 siblings, 2 replies; 10+ messages in thread From: Ian Campbell @ 2016-01-19 9:38 UTC (permalink / raw) To: Jan Beulich, Andrew Cooper; +Cc: Xen-devel 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 ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [PATCH] xen: Improvements to clean and distclean targets 2016-01-19 9:38 ` Ian Campbell @ 2016-01-19 10:06 ` Juergen Gross 2016-01-19 10:11 ` Ian Campbell 2016-01-20 10:22 ` George Dunlap 1 sibling, 1 reply; 10+ messages in thread From: Juergen Gross @ 2016-01-19 10:06 UTC (permalink / raw) To: Ian Campbell, Jan Beulich, Andrew Cooper; +Cc: 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 ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [PATCH] xen: Improvements to clean and distclean targets 2016-01-19 10:06 ` Juergen Gross @ 2016-01-19 10:11 ` Ian Campbell 0 siblings, 0 replies; 10+ messages in thread From: Ian Campbell @ 2016-01-19 10:11 UTC (permalink / raw) To: Juergen Gross, Jan Beulich, Andrew Cooper; +Cc: Xen-devel 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. ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [PATCH] xen: Improvements to clean and distclean targets 2016-01-19 9:38 ` Ian Campbell 2016-01-19 10:06 ` Juergen Gross @ 2016-01-20 10:22 ` George Dunlap 1 sibling, 0 replies; 10+ messages in thread From: George Dunlap @ 2016-01-20 10:22 UTC (permalink / raw) To: Ian Campbell; +Cc: Andrew Cooper, Jan Beulich, Xen-devel 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 ^ permalink raw reply [flat|nested] 10+ messages in thread
end of thread, other threads:[~2016-01-20 10:22 UTC | newest] Thread overview: 10+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2016-01-18 16:27 [PATCH] xen: Improvements to clean and distclean targets Andrew Cooper 2016-01-18 16:41 ` Jan Beulich 2016-01-18 16:45 ` Andrew Cooper 2016-01-18 16:57 ` Jan Beulich 2016-01-18 18:19 ` Andrew Cooper 2016-01-19 8:43 ` Jan Beulich 2016-01-19 9:38 ` Ian Campbell 2016-01-19 10:06 ` Juergen Gross 2016-01-19 10:11 ` Ian Campbell 2016-01-20 10:22 ` George Dunlap
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.