Re: [PATCH 1/2 v2] bitbake.conf: Add SECURITY_*FLAGS overridable definition

[Saul Wold <sgw@linux.intel.com>]

On 06/28/2013 12:51 PM, Phil Blundell wrote:
> On Fri, 2013-06-28 at 12:23 -0700, Saul Wold wrote:
>> This will allow for SECURITY_CFLAGS and SECURITY_LDFLAGS to be
>> defined in the security_flags.inc and override the empty default.
>
> Why can't security_flags.inc just append to CFLAGS and LDFLAGS
> respectively, or some other set of variables that already exists?
>
So, if I remember correctly there was issues with this because there are 
a number of packages that have to modify specifically the security 
related flags (see the list in security_flags.inc), the ordering/timing 
of being able to due that correctly did not allow for setting it 
directly in CFLAGS or TARGET_CFLAGS.

> Creating new variables in bitbake.conf does have a cost in terms of
> parse time and memory footprint for every recipe.  If the variables are
> referenced in ${CFLAGS} etc then it also adds an extra substitution
> whenever CFLAGS is expanded.  The cost of those things isn't enormous,
> but it isn't zero either and adding them isn't something that we should
> do capriciously.
>
I understand, and RP and I talked about this, we needed a separate 
variable to ensure the correct substitution occurred for those that 
needed to disable or remove certain flags.

Sau!


> p.
>
>
>
>