Re: [Xen-devel] [PATCH] build: remove .d files from xen/ on a clean

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> On 25.11.15 at 14:07, <jonathan.creekmore@xxxxxxxxx> wrote:

>> On Nov 25, 2015, at 2:58 AM, Jan Beulich <JBeulich@xxxxxxxx> wrote:
>> 
>>>>> On 24.11.15 at 19:19, <jonathan.creekmore@xxxxxxxxx> wrote:
>> 
>>>> On Nov 24, 2015, at 11:30 AM, Jan Beulich <JBeulich@xxxxxxxx> wrote:
>>>> 
>>>>>>> On 24.11.15 at 18:22, <jonathan.creekmore@xxxxxxxxx> wrote:
>>>> 
>>>>>> On Nov 24, 2015, at 11:16 AM, Jonathan Creekmore 
>>>>> <jonathan.creekmore@xxxxxxxxx> 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. 

Even if the rule deleted them, a failed or interrupted build could
leave them there. I'll therefore apply your patch as is.

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

This actually points out a worse problem: Dependencies are currently
broken for all the files built from their parent directory. I wrongly used
$(basename ...) in the DEPS generation, which I'll send a patch for
shortly. Once fixed, the "clean" aspect will be fixed at once.

Jan

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