[PATCH] xen: Improvements to clean and distclean targets

[PATCH] xen: Improvements to clean and distclean targets

[Andrew Cooper]

* 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

Re: [PATCH] xen: Improvements to clean and distclean targets

[Jan Beulich]

>>> 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

Re: [PATCH] xen: Improvements to clean and distclean targets

[Andrew Cooper]

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

Re: [PATCH] xen: Improvements to clean and distclean targets

[Jan Beulich]

>>> 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

Re: [PATCH] xen: Improvements to clean and distclean targets

[Andrew Cooper]

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

Re: [PATCH] xen: Improvements to clean and distclean targets

[Jan Beulich]

>>> 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

Re: [PATCH] xen: Improvements to clean and distclean targets

[Ian Campbell]

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

Re: [PATCH] xen: Improvements to clean and distclean targets

[Juergen Gross]

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

Re: [PATCH] xen: Improvements to clean and distclean targets

[Ian Campbell]

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.

Re: [PATCH] xen: Improvements to clean and distclean targets

[George Dunlap]

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