From: ChenQi <Qi.Chen@windriver.com>
To: Paul Eggleton <paul.eggleton@linux.intel.com>
Cc: openembedded-core@lists.openembedded.org
Subject: Re: [PATCH 2/3] populate_sdk_ext: consider custom configuration in local.conf
Date: Tue, 9 Jun 2015 14:41:53 +0800 [thread overview]
Message-ID: <55768AB1.9090607@windriver.com> (raw)
In-Reply-To: <4741340.pDCvDy9tKk@peggleto-mobl.ger.corp.intel.com>
On 06/04/2015 10:11 PM, Paul Eggleton wrote:
> Hi Qi,
>
> On Wednesday 27 May 2015 14:09:39 Chen Qi wrote:
>> Copy the contents of local.conf under TOPDIR into the final generated
>> local.conf. In this way, custom settings are also made into the final
>> local.conf like IMAGE_INSTALL, DISTRO_FEATURES, VIRTUAL-RUNTIME_xxx, etc.
>>
>> Before this change, installing extensible SDK would usually report failure
>> when preparing the build system if the user has custom configuration for
>> DISTRO_FEATURES in local.conf. Also, items in IMAGE_INSTALL_append in
>> local.conf also don't get built correctly.
>>
>> This patch solves the above problem.
>>
>> A blacklist mechanism is also introduced so that we can blacklist variables
>> that should not be copied into the final local.conf file. Currently, the
>> blacklist contains 'TMPDIR', 'SSTATE_DIR', 'DL_DIR', 'STAMPS_DIR',
>> 'BASE_WORKDIR' and 'DEPLOY_DIR'. What these variables have in common is
>> that they are set in bitbake.conf using '?=' or '??='.
>>
>> In addition, we check to avoid any setting that might lead to host path
>> bleeding into SDK's configuration.
>>
>> [YOCTO #7616]
>>
>> Signed-off-by: Chen Qi <Qi.Chen@windriver.com>
>> ---
>> meta/classes/populate_sdk_ext.bbclass | 23 +++++++++++++++++++++++
>> 1 file changed, 23 insertions(+)
>>
>> diff --git a/meta/classes/populate_sdk_ext.bbclass
>> b/meta/classes/populate_sdk_ext.bbclass index 2fc4c11..49ba26b 100644
>> --- a/meta/classes/populate_sdk_ext.bbclass
>> +++ b/meta/classes/populate_sdk_ext.bbclass
>> @@ -16,6 +16,7 @@ SDK_RDEPENDS_append_task-populate-sdk-ext = "
>> ${SDK_TARGETS}" SDK_RELOCATE_AFTER_INSTALL_task-populate-sdk-ext = "0"
>>
>> SDK_META_CONF_WHITELIST ?= "MACHINE DISTRO PACKAGE_CLASSES"
>> +SDK_META_CONF_BLACKLIST ?= "TMPDIR DL_DIR SSTATE_DIR STAMPS_DIR
>> BASE_WORKDIR DEPLOY_DIR"
>>
>> SDK_TARGETS ?= "${PN}"
>> OE_INIT_ENV_SCRIPT ?= "oe-init-build-env"
>> @@ -114,6 +115,28 @@ python copy_buildsystem () {
>> f.write('# this configuration provides, it is strongly suggested
>> that you set\n') f.write('# up a proper instance of the full build system
>> and use that instead.\n\n')
>>
>> + # Copy configurations from the current local.conf
>> + builddir = d.getVar('TOPDIR', True)
>> + with open(builddir + '/conf/local.conf', 'r') as lf:
>> + varblacklist = d.getVar('SDK_META_CONF_BLACKLIST',
>> True).split() + skip = False
>> + for line in lf:
>> + line = line.lstrip()
>> + if line.startswith('#'):
>> + continue
>> + # avoid host path bleeding into SDK configuration
>> + if line.find('"/') != -1:
>> + continue
>> + for varname in varblacklist:
>> + if line.startswith(varname):
>> + skip = True
>> + break
>> + if not skip:
>> + f.write(line)
>> + skip = False
>> + f.write('\n')
>> +
>> + # Configurations in local.conf which are specific for extensible
>> SDK f.write('INHERIT += "%s"\n\n' % 'uninative')
>> f.write('CONF_VERSION = "%s"\n\n' % d.getVar('CONF_VERSION'))
> I've been thinking about this; since I've recently added edit_metadata() in
> bitbake's lib/bb/utils.py, it would make sense to use that rather than adding
> another piece of code that effectively parses bitbake configuration files (though
> I know this isn't adding much). I know this series has been going back and
> forth for a while now and the delays have largely been my fault, so I'd be
> happy to make this change and resend the series - it's up to you.
>
> Cheers,
> Paul
>
Hi Paul,
Thanks for your suggestion.
I've been looking into edit_metadata(). But it seems that it's used to
modify *specific* variables.
In this case, we don't know which variables we are going to skip in
local.conf. We just know that they start with '/'. So I don't see how to
do it.
I'm not sure if I understand things wrong. Please point it out directly
if I've missed something.
Best Regards,
Chen Qi
next prev parent reply other threads:[~2015-06-09 6:41 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-05-27 6:09 [PATCH 0/3] Extensible SDK: 3 fixes Chen Qi
2015-05-27 6:09 ` [PATCH 1/3] populate_sdk_ext: install the latest buildtools-tarball Chen Qi
2015-05-27 18:54 ` Christopher Larson
2015-05-27 21:26 ` Randy Witt
2015-05-27 22:13 ` Christopher Larson
2015-05-27 6:09 ` [PATCH 2/3] populate_sdk_ext: consider custom configuration in local.conf Chen Qi
2015-06-04 14:11 ` Paul Eggleton
2015-06-09 6:41 ` ChenQi [this message]
2015-06-09 8:59 ` Paul Eggleton
2015-05-27 6:09 ` [PATCH 3/3] copy_buildsystem: make sure bitbake directory is copied Chen Qi
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=55768AB1.9090607@windriver.com \
--to=qi.chen@windriver.com \
--cc=openembedded-core@lists.openembedded.org \
--cc=paul.eggleton@linux.intel.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.