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