qemu-devel
[Top][All Lists]
Advanced

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

Re: [Qemu-devel] [PATCH RESEND for-1.4] make_device_config.sh: Fix targe


From: Andreas Färber
Subject: Re: [Qemu-devel] [PATCH RESEND for-1.4] make_device_config.sh: Fix target path in generated dependency file
Date: Thu, 21 Feb 2013 15:28:50 +0100
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130105 Thunderbird/17.0.2

Am 21.02.2013 14:19, schrieb Paolo Bonzini:
> Il 21/02/2013 13:52, Andreas Färber ha scritto:
>> As discussed on IRC, what happened here it seems is that at the time of
>> writing the patch (two releases ago) we had -include *.d in
>> Makefile.target, so the generated .mak.d files were effectively included
>> from two Makefiles, working for one but not for the other. So
>> effectively we were observing race conditions between Makefile and
>> x86_64-softmmu/Makefile a.k.a. Makefile.target.
>> This seems to have gotten fixed through Paolo's nested-vars handling in
>> rules.mak, which only does -include *.d for directories listed in obj-y
>> etc. So my patch was broken and is now completely broken. :(
>>
>> However I don't see in the curent Makefile.target and rules.mak where
>> the *.d files are being included today
> 
> Makefile.target also includes Makefile.objs and calls the unnesting
> machinery in rules.mak.  The machinery then includes the .d files.

Sure, I'm aware of the unnesting. What I meant is that unnest-vars in
rules.mak seems to -include only subdirectories added to the
to-be-unnested variables $(var) iiuc. Where does ./*.d get -include'd
though? There's no obj-y += ./ to trigger that.

Andreas

P.S. I'm preparing a revert of my patch and intend to change the file
placement to fix the conflict and avoid more misunderstandings.

> 
> Paolo
> 
>> , so we may have discovered a
>> different issue that if fixed may reintroduce the original bug again...
> 


-- 
SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer; HRB 16746 AG Nürnberg



reply via email to

[Prev in Thread] Current Thread [Next in Thread]