[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-stable] [PATCH RESEND for-1.4] make_device_config.sh: Fix targ
From: |
Andreas Färber |
Subject: |
Re: [Qemu-stable] [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