[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
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |