[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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



On Tue, 2016-01-19 at 01:43 -0700, Jan Beulich wrote:
> > > > On 18.01.16 at 19:19, <andrew.cooper3@xxxxxxxxxx> wrote:
> > On 18/01/16 16:57, Jan Beulich wrote:
> > > > > > On 18.01.16 at 17:45, <andrew.cooper3@xxxxxxxxxx> wrote:
> > > > On 18/01/16 16:41, Jan Beulich wrote:
> > > > > > > > On 18.01.16 at 17:27, <andrew.cooper3@xxxxxxxxxx> 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@xxxxxxxxxxxxx
> http://lists.xen.org/xen-devel

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.