[prev in list] [next in list] [prev in thread] [next in thread] 

List:       openembedded-core
Subject:    [OE-core] [PATCH 1/2 v2] bitbake.conf: Add SECURITY_*FLAGS overridable definition
From:       raj.khem () gmail ! com (Khem Raj)
Date:       2013-06-28 22:17:51
Message-ID: A496288F-F0AD-4013-9078-AB68461E1178 () gmail ! com
[Download RAW message or body]


On Jun 28, 2013, at 1:19 PM, Saul Wold <sgw at linux.intel.com> wrote:

> 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.

can you use append|prepend override ?

> 
> > 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.
> > 
> > 
> > 
> > 
> _______________________________________________
> Openembedded-core mailing list
> Openembedded-core at lists.openembedded.org
> http://lists.openembedded.org/mailman/listinfo/openembedded-core


[prev in list] [next in list] [prev in thread] [next in thread]