Re: [Xen-devel] [PATCH] build: fix clean rule to cover objects in unvisited subdirs

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> On 01.12.15 at 17:34, <jonathan.creekmore@xxxxxxxxx> wrote:
>> On Dec 1, 2015, at 10:07 AM, Jan Beulich <JBeulich@xxxxxxxx> wrote:
>> 
>> For one build run, yes. But then you can (a) build individual object
>> files and (b) as mentioned above change configuration (implying
>> that you know what you're doing). Also you could, using the
>> example above, do a kexec=y build, then a kexec=n one, then
>> notice you needed to clean in between, so you then clean using
>> kexec=n and build again with that option, but cleaning again
>> would still leave the kexec files around.
>> 
>> And btw., we have a similar issue already when you switch
>> between arches (no cleaning happens cross-arch).
> 
> OK, so you are working on a different assumption than I was. I was
> treating the clean rule as needing to be run when you are wanting to
> explicitly rebuild all object files needed for the current build 
> configuration 
> (i.e., only cleaning files that would be linked into the current hypervisor 
> build).
> It sounds like you are expecting the clean rule to clean out all object
> files no matter whether they are part of the current build configuration
> or not. 
> 
> Working on that assumption, it seems like running a:
>     find . -name â*.oâ -type f -delete 
> from the xen/ directory would accomplish that and would be less
> fragile than trying to grab various different variables and munge
> them to try to grab all possible .o files specified by the system. Plus,
> the find command would likely execute quicker. 
> 
> Does something like that seem acceptable?

I can't see an immediate reason why it would not be, as long
as it's clear that this won't eliminate the need to recurse into
the subdirectories. But I'd certainly recommend to wait for
other feedback (namely by other hypervisor maintainers)
before you go that route.

Also please note that -delete is not a standard primary, so
would need replacing.

Also the same global approach could then perhaps be used to
remove all the .*.d files.

Jan

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