[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

>>> On 01.12.15 at 16:52, <jonathan.creekmore@xxxxxxxxx> wrote:

>> On Dec 1, 2015, at 6:41 AM, Jan Beulich <JBeulich@xxxxxxxx> wrote:
>>>>> On 30.11.15 at 18:29, <jonathan.creekmore@xxxxxxxxx> wrote:
>>> --- a/xen/Rules.mk
>>> +++ b/xen/Rules.mk
>>> @@ -173,7 +173,7 @@ FORCE:
>>> .PHONY: clean
>>> clean:: $(addprefix _clean_, $(subdir-all))
>>> -   rm -f *.o *~ core $(DEPS)
>>> +   rm -f *.o *~ core $(DEPS) $(obj-y)
>> While for the moment it would do, using a minimalistic approach
>> like this will make us touch this again the moment we gain files in
>> subdirectories that can be built just optionally. At the very least
>> I'd therefore suggest also adding $(obj-n) and $(obj-) here. It
>> might even be reasonable to grab subdirectories from $(obj-...)
>> and add $(foreach d,$(filtered-subdirs), $(d)/*.o). Or, completely
>> differently, have xen/common/Makefile just have an add-on
>> clean:: (and require this also for future other cases like this).
> I am not sure why this would require us to touch it again if we gain
> files in subdirectories that can be built optionally. If you are running
> a clean using the same configuration as you built, then the âoptionalâ
> subdirectories would be in the subdir-all list, so that subdirectory
> would be processed just like it is now.

The question isn't about things referenced through $(subdir-all) or
however it is called, but about files with path name conditionally
appearing in $(obj-y). Leaving aside the path name aspect, just
consider you do a build with kexec=y and later a clean with
kexec=n, which would (if the files were in subdirectories, or if
you indeed removed *.o from the clean rule) leave these around.

> Adding in obj-n and obj- seems
> to imply that, for the current options selected, you are concerned about
> object files showing up that you explicitly stated are not to be built 
> (since that is how they show up in the obj-n list). My understanding of
> the build system is that the only object files built are in obj-y for each
> subdirectory. 

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

> Initially, I tried eliminating the *.o completely and just pulling in obj-y 
> and
> obj-bin-y to the clean rule to be more like the Linux kernel clean rules, 
> but I did not immediately see how, with $FOO.init.o in the obj-bin-y list,
> I was seeing $FOO.o objects left behind instead. Thus, I left the *.o to
> clean those files up.

Because for $FOO.init.o the corresponding $FOO.o wouldn't appear
in $(obj-y) - quite obviously we don't want to link both objects. I.e.
you need to clear not just $(obj-y) but also $(obj-bin-y) and
$(patsubst %.init.o,%.o,$(obj-bin-y)).



Xen-devel mailing list



Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.