Re: [PATCH] build: fix dependencies for files compiled from their parent directory

From: "Jan Beulich" <JBeulich@suse.com>
To: Ian Campbell <ian.campbell@citrix.com>
Cc: Jonathan Creekmore <jonathan.creekmore@gmail.com>,
	Tim Deegan <tim@xen.org>, Keir Fraser <keir@xen.org>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>,
	xen-devel <xen-devel@lists.xenproject.org>
Subject: Re: [PATCH] build: fix dependencies for files compiled from their parent directory
Date: Thu, 26 Nov 2015 03:38:15 -0700	[thread overview]
Message-ID: <5656EF2702000078000B94D4@prv-mh.provo.novell.com> (raw)
In-Reply-To: <1448531462.17688.155.camel@citrix.com>

>>> On 26.11.15 at 10:51, <ian.campbell@citrix.com> wrote:
> On Thu, 2015-11-26 at 00:43 -0700, Jan Beulich wrote:
>> > > > On 25.11.15 at 17:26, <ian.campbell@citrix.com> wrote:
>> > On Wed, 2015-11-25 at 09:16 -0700, Jan Beulich wrote:
>> > > The use of $(basename ...) here was wrong (yet I'm sure I tested it).
>> > 
>> > Is the issue here that xen/arch/x86/x86_64/.compat.o.d ought really to
>> > be
>> > xen/arch/x86/.x86_64.compat.o.d?
>> 
>> No, xen/arch/x86/x86_64/.compat.o.d is the correct name. Just
>> that $(dir $(1)).$(basename $(notdir $(1))).d produces
>> xen/arch/x86/x86_64/.compat.d (i.e. strips the .o, which is not in
>> line with $(@D)/.$(@F).d used to generate those files), and hence
>> neither dependency tracking nor cleaning work.
> 
> My tree, which was last built with 98b69a010c24 has:
> 
>     ianc@cosworth    :committer-amd64.git$ find xen -name .\*compat\*
>     xen/arch/x86/.compat.o.d
>     xen/arch/x86/x86_64/.compat.o.d
>     xen/arch/x86/efi/.compat.o.d
>     ianc@cosworth    :committer-amd64.git$ 
> 
> Which is very odd, since the prevailing xen/Rules.mk has:
> 
>     define gendep
>         ifneq ($(1),$(subst /,:,$(1)))
>             DEPS += $(dir $(1)).$(basename $(notdir $(1))).d
>         endif
>     endef
> 
> Which I agree looks as if it should have stripped the .o as you describe,
> but it seems not to have done so. AIUI makes "basename" differs from the
> CLI basename(1) in that the make one will always strip 

You're looking at the wrong thing I'm afraid: How the files get named
depends on the $(@D)/.$(@F).d thing in CFLAGS. What gets put in
$(DEPS) (and hence gets included) depends on the construct above.
So the correctly named files get generated, but they get neither
included for proper dependency checking, nor would they get
deleted by the "clean" rule. And since the inclusion of $(DEPS) has a
minus sign in front, make wouldn't complain about not finding these
files.

Jan