[OE-core] [PATCH 1/2] populate_sdk_ext: consider custom configuration in local.conf

[Richard Purdie]

On Wed, 2015-04-29 at 09:54 +0100, Paul Eggleton wrote:
> Hi Qi,
> 
> On Wednesday 29 April 2015 16:08:36 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 'SSTATE_DIR' and 'DL_DIR'.
> > 
> > [YOCTO #7616]
> > 
> > Signed-off-by: Chen Qi <Qi.Chen at windriver.com>
> > ---
> >  meta/classes/populate_sdk_ext.bbclass | 20 ++++++++++++++++++++
> >  1 file changed, 20 insertions(+)
> > 
> > diff --git a/meta/classes/populate_sdk_ext.bbclass
> > b/meta/classes/populate_sdk_ext.bbclass index dc2c58e..7925ece 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 ?= "DL_DIR SSTATE_DIR"
> 
> I'm not totally opposed to this approach but we are going to have to get the 
> default list right if we are going to do it - e.g. you've missed the fairly 
> obvious TMPDIR. There are quite a large number of other variables the user 
> might set that should be blacklisted - potentially any variable that points to 
> a location where the build system would write files (DEPLOY_DIR, DEPLOY_DIR_*, 
> WORKDIR, T, S, B, ...). We might go a step further and use the data dictionary 
> to check if the value evaluates to somewhere outside of ${TMPDIR} (if we first 
> make a copy of d and set TMPDIR to a dummy value); this way we would allow 
> adjustments within TMPDIR but not outside of it.
> 
> My other concern (perhaps a pet issue of mine) is that people are far too 
> reliant on putting things in local.conf that they really shouldn't. On the 
> other hand building a potentially broken SDK or at least one that doesn't 
> match up with the image is worse, but I'm still concerned about the way 
> local.conf is often abused.

One thing we could do programatically is to build the bash config hash
with and without local.conf. If they match, local.conf isn't influencing
the build checksums. If they don't match, local.conf has something
problematic in it and we could error and tell the user to fix it?

This would also cover site.conf, auto.conf and the other conf files we
can detect.

Cheers,

Richard