Openembedded Core Discussions
 help / color / mirror / Atom feed
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


  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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox