Target_cflags is an exported variable. It affects the checksums of every task. Not ideal, but that's how it is today.<br><div class="gmail_quote"><div dir="ltr">On Mon, Feb 8, 2016 at 5:10 PM Andre McCurdy <<a href="mailto:armccurdy@gmail.com">armccurdy@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On Mon, Feb 8, 2016 at 4:01 PM, Mark Hatle <<a href="mailto:mark.hatle@windriver.com" target="_blank">mark.hatle@windriver.com</a>> wrote:<br>
> On 2/8/16 5:43 PM, Andre McCurdy wrote:<br>
>> On Mon, Feb 8, 2016 at 3:00 PM, Burton, Ross <<a href="mailto:ross.burton@intel.com" target="_blank">ross.burton@intel.com</a>> wrote:<br>
>>><br>
>>> On 8 February 2016 at 20:03, Andre McCurdy <<a href="mailto:armccurdy@gmail.com" target="_blank">armccurdy@gmail.com</a>> wrote:<br>
>>>><br>
>>>> Can you give an example? Looking at native.bbclass it seems to replace<br>
>>>> TARGET_CFLAGS with BUILD_CFLAGS, not manipulate it.<br>
>>><br>
>>> Sure, so in doing a native build TARGET_CFLAGS is used. But as<br>
>>> security_flags.inc was using TARGET_CFLAGS_append, the end result was<br>
>>> BUILD_CFLAGS appended with the security flags.<br>
>><br>
>> Yes, for native, TARGET_CFLAGS will end up being "${BUILD_CFLAGS}<br>
>> ${SECURITY_CFLAGS}".<br>
>><br>
>> However it shouldn't matter - native.bbclass sets CFLAGS to<br>
>> BUILD_CFLAGS, not TARGET_CFLAGS.<br>
>><br>
>> Do you have an example where host gcc can legitimately be invoked with<br>
>> TARGET_CFLAGS?<br>
><br>
> You have to remember the order of the operators. _append says to make the<br>
> append, AFTER everything else has been evaluated (and before _remove). This<br>
> includes override behaviors.<br>
><br>
> So if you do:<br>
><br>
> TARGET_CFLAGS = "-deadbeef"<br>
> BUILD_CFLAGS = "-badc0ffee"<br>
> TARGET_CFLAGS_append = " -foobar"<br>
> TARGET_CFLAGS = "${BUILD_CFLAGS}"<br>
><br>
> The final value of TARGET_CFLAGS is "-badc0ffee -foobar"<br>
><br>
> Thus by changing the append to:<br>
><br>
> TARGET_CFLAGS_append_class-target = " -foobar"<br>
> TARGET_CFLAGS_class-native = "${BUILD_CFLAGS}"<br>
><br>
> In the case where the 'class-target' is the override you will get:<br>
><br>
> TARGET_CFLAGS = "-deadbeef -foobar"<br>
><br>
> In the case where the 'class-native' is the override you will get:<br>
><br>
> TARGET_CFLAGS = "-badc0ffee"<br>
<br>
I'm not disputing that TARGET_CFLAGS can contain something bogus for a<br>
class-native build.<br>
<br>
I'm asking why does it matter?<br>
<br>
Setting TARGET_CFLAGS at all in native.bbclass is fairly recent and<br>
seems to be a workaround to avoid churning sstate:<br>
<br>
<a href="http://git.openembedded.org/openembedded-core/commit/?id=05a70ac30b37cab0952f1b9df501993a9dec70da" rel="noreferrer" target="_blank">http://git.openembedded.org/openembedded-core/commit/?id=05a70ac30b37cab0952f1b9df501993a9dec70da</a><br>
<br>
Is that perhaps still the real reason to avoid modifying TARGET_CFLAGS<br>
for a native build?<br>
<br>
<br>
> --Mark<br>
--<br>
_______________________________________________<br>
Openembedded-core mailing list<br>
<a href="mailto:Openembedded-core@lists.openembedded.org" target="_blank">Openembedded-core@lists.openembedded.org</a><br>
<a href="http://lists.openembedded.org/mailman/listinfo/openembedded-core" rel="noreferrer" target="_blank">http://lists.openembedded.org/mailman/listinfo/openembedded-core</a><br>
</blockquote></div>