[PATCH] build: remove .d files from xen/ on a clean

[PATCH] build: remove .d files from xen/ on a clean

[Jonathan Creekmore]

Dependency files were getting left behind in the xen
directory (since 8b6ef9c152edceabecc7f90c811cd538a7b7a110),
so append the $(DEPS) to the clean rule that runs in the
hypervisor directory.

CC: Ian Campbell <ian.campbell@citrix.com>
CC: Ian Jackson <ian.jackson@eu.citrix.com>
CC: Jan Beulich <jbeulich@suse.com>
CC: Keir Fraser <keir@xen.org>
CC: Tim Deegan <tim@xen.org>
Signed-off-by: Jonathan Creekmore <jonathan.creekmore@gmail.com>
---
 xen/Makefile | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/xen/Makefile b/xen/Makefile
index c556198..fa9cf0a 100644
--- 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)
 	rm -f include/asm-*/asm-offsets.h
 	rm -f .banner
 
-- 
2.4.9 (Apple Git-60)

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

[Jan Beulich]

>>> On 24.11.15 at 17:56, <jonathan.creekmore@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.

Jan

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

[Doug Goldstein]

[-- Attachment #1.1: Type: text/plain, Size: 2031 bytes --]

On 11/24/15 11:07 AM, Jan Beulich wrote:
>>>> On 24.11.15 at 17:56, <jonathan.creekmore@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.
> 
> Jan
> 

Andrew Cooper, myself and the author see the following after running
make && make clean without this patch:

$ ls -la xen
total 124
drwxrwxr-x 10 doug doug  4096 Nov 24 11:09 .
drwxrwxr-x 12 doug doug  4096 Nov 24 10:53 ..
drwxrwxr-x  4 doug doug  4096 Sep 16 10:48 arch
drwxrwxr-x 10 doug doug 12288 Nov 24 11:09 common
-rw-rw-r--  1 doug doug 19116 Jul 31 09:55 COPYING
drwxrwxr-x  2 doug doug  4096 Nov 24 11:09 crypto
drwxrwxr-x  8 doug doug  4096 Nov 24 11:09 drivers
drwxrwxr-x 13 doug doug  4096 Nov 24 11:09 include
-rw-rw-r--  1 doug doug   502 Nov 24 10:53 Kconfig
-rw-rw-r--  1 doug doug  8639 Nov 24 10:53 Makefile
-rw-rw-r--  1 doug doug  5840 Nov 24 10:55 Rules.mk
drwxrwxr-x  3 doug doug  4096 Nov 24 10:53 scripts
drwxrwxr-x  2 doug doug  4096 Nov 24 11:09 tools
-rw-rw-r--  1 doug doug   279 Nov 24 11:00 ..xen.efi.0r.o.d
-rw-rw-r--  1 doug doug   374 Nov 24 11:00 ..xen.efi.0s.o.d
-rw-rw-r--  1 doug doug   279 Nov 24 11:00 ..xen.efi.1r.o.d
-rw-rw-r--  1 doug doug   374 Nov 24 11:00 ..xen.efi.1s.o.d
-rw-rw-r--  1 doug doug   374 Nov 24 11:00 ..xen-syms.0.o.d
-rw-rw-r--  1 doug doug   374 Nov 24 11:00 ..xen-syms.1.o.d
drwxrwxr-x  3 doug doug  4096 Nov 24 11:09 xsm


-- 
Doug Goldstein


[-- Attachment #1.2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 959 bytes --]

[-- Attachment #2: Type: text/plain, Size: 126 bytes --]

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

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

[Jonathan Creekmore]

> On Nov 24, 2015, at 11:07 AM, Jan Beulich <jbeulich@suse.com> wrote:
> 
>>>> On 24.11.15 at 17:56, <jonathan.creekmore@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.
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

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

[Jonathan Creekmore]

[-- Attachment #1.1: Type: text/plain, Size: 1428 bytes --]


> On Nov 24, 2015, at 11:16 AM, Jonathan Creekmore <jonathan.creekmore@gmail.com> wrote:
> 
>> 
>> On Nov 24, 2015, at 11:07 AM, Jan Beulich <jbeulich@suse.com> wrote:
>> 
>>>>> On 24.11.15 at 17:56, <jonathan.creekmore@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.


[-- Attachment #1.2: Type: text/html, Size: 6344 bytes --]

[-- Attachment #2: Type: text/plain, Size: 126 bytes --]

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

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

[Jan Beulich]

>>> On 24.11.15 at 18:22, <jonathan.creekmore@gmail.com> wrote:

>> On Nov 24, 2015, at 11:16 AM, Jonathan Creekmore 
> <jonathan.creekmore@gmail.com> wrote:
>>> On Nov 24, 2015, at 11:07 AM, Jan Beulich <jbeulich@suse.com> wrote:
>>>>>> On 24.11.15 at 17:56, <jonathan.creekmore@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

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

[Jonathan Creekmore]

> On Nov 24, 2015, at 11:30 AM, Jan Beulich <JBeulich@suse.com> wrote:
> 
>>>> On 24.11.15 at 18:22, <jonathan.creekmore@gmail.com> wrote:
> 
>>> On Nov 24, 2015, at 11:16 AM, Jonathan Creekmore 
>> <jonathan.creekmore@gmail.com> wrote:
>>>> On Nov 24, 2015, at 11:07 AM, Jan Beulich <jbeulich@suse.com> wrote:
>>>>>>> On 24.11.15 at 17:56, <jonathan.creekmore@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.

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. 


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

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

[Jan Beulich]

>>> On 24.11.15 at 19:19, <jonathan.creekmore@gmail.com> wrote:

>> On Nov 24, 2015, at 11:30 AM, Jan Beulich <JBeulich@suse.com> wrote:
>> 
>>>>> On 24.11.15 at 18:22, <jonathan.creekmore@gmail.com> wrote:
>> 
>>>> On Nov 24, 2015, at 11:16 AM, Jonathan Creekmore 
>>> <jonathan.creekmore@gmail.com> wrote:
>>>>> On Nov 24, 2015, at 11:07 AM, Jan Beulich <jbeulich@suse.com> wrote:
>>>>>>>> On 24.11.15 at 17:56, <jonathan.creekmore@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.
> 
> 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.

Jan

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

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

[Jonathan Creekmore]

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

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

[Jan Beulich]

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

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

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@lists.xen.org
http://lists.xen.org/xen-devel