> On Nov 25, 2015, at 2:58 AM, Jan Beulich <jbeul...@suse.com> wrote: > >>>> On 24.11.15 at 19:19, <jonathan.creekm...@gmail.com> wrote: > >>> On Nov 24, 2015, at 11:30 AM, Jan Beulich <jbeul...@suse.com> wrote: >>> >>>>>> On 24.11.15 at 18:22, <jonathan.creekm...@gmail.com> wrote: >>> >>>>> On Nov 24, 2015, at 11:16 AM, Jonathan Creekmore >>>> <jonathan.creekm...@gmail.com> wrote: >>>>> >>>>> So, the files in xen/ were the dependencies files for xen.efi and >>>>> xen-syms that were getting left behind. $(DEPS) appears to always >>>>> have ‘.*.d’ in it, based on me putting an echo into the clean rule to >>>>> print it out. However, looking at this, I am also seeing ‘.d’ files left >>>>> behind in xen/common/compat that I did not notice before. >>>> >>>> Actually, looking closer at it, xen/common/compat does not appear to be >>>> cleaning at all, so I think that is a separate, unrelated issue. >>> >>> That would be quite related, as it would be a result of the same >>> commit. >> >> Yeah, I now see where that change got introduced. I don’t see a clear way of >> cleaning >> those objects files since the build system no longer goes into the >> common/compat directory at >> all. The existing clean rules walk all of the subdirectories, cleaning >> object files and dependency >> files as it goes. > > But wouldn't the way DEPS gets populated in xen/Rules.mk cover for > this? If so, the alternative to your original patch might be to simply > rm those ..xen*.o.d files right in the $(TARGET)-syms and > $(TARGET).efi rules (along with their corresponding > $(@D)/.$(@F).[0-9]* getting removed, due to which those .o.d > ones are of no use anyway). Or maybe it should really do both, > considering that *.o get removed by _clean too. >
So, I think we are talking a bit at cross purposes here. There are two problems as I see it: 1. Dependency files get left in the xen/ directory for xen and xen-syms. Those dependency files just started appearing in the xen/ directory when the dependency generation was redone and the clean rule for the top-level directory did not handle cleaning dependency files in the top-level, because it has no source files. That is what my patch was specifically aiming at fixing. The way DEPS gets populated in xen/Rules.mk does cover it, but since DEPS was never in that top-level directory, it wasn’t clearing the dep files that were left in that directory. However, you could make the argument that the real problem is that the dependency files are being dropped in that directory in the first place. 2. The xen/common/compat directory is not being cleaned at all, although there are .o and .o.d files left in that directory. My patch does not handle that and was never meant to handle that. Given the way the clean rule works, I don’t see how to clean out the files in that directory now that it is no longer in the subdir-y list without just special casing it, which is kind of gross. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
