>>> 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: >>> On Nov 24, 2015, at 11:07 AM, Jan Beulich <jbeul...@suse.com> wrote: >>>>>> On 24.11.15 at 17:56, <jonathan.creekm...@gmail.com> wrote: >>>> --- a/xen/Makefile >>>> +++ b/xen/Makefile >>>> @@ -88,7 +88,7 @@ _clean: delete-unfresh-files >>>> $(MAKE) -f $(BASEDIR)/Rules.mk -C xsm clean >>>> $(MAKE) -f $(BASEDIR)/Rules.mk -C crypto clean >>>> $(MAKE) -f $(BASEDIR)/Rules.mk -C arch/$(TARGET_ARCH) clean >>>> - rm -f include/asm *.o $(TARGET) $(TARGET).gz $(TARGET).efi >>>> $(TARGET)-syms > *~ core >>>> + rm -f include/asm *.o $(TARGET) $(TARGET).gz $(TARGET).efi >>>> $(TARGET)-syms > *~ core $(DEPS) >>> >>> Is this really a problem only in xen/ ? The referenced commit clearly >>> introduces "stray" *.d files elsewhere. Also there aren't any source >>> files in xen/, so I'd expect $(DEPS) to be empty. Please clarify. >> >> 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. Jan _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
