[OE-core] [PATCH 9/9] populate_sdk_ext: add extensible SDK

[Richard Purdie]

On Mon, 2015-02-23 at 15:00 -0300, Otavio Salvador wrote:
> On Mon, Feb 23, 2015 at 2:54 PM, Paul Eggleton
> <paul.eggleton at linux.intel.com> wrote:
> > On Monday 23 February 2015 14:41:34 Otavio Salvador wrote:
> >> On Mon, Feb 23, 2015 at 2:00 PM, Paul Eggleton
> >> <paul.eggleton at linux.intel.com> wrote:
> >> > From: Randy Witt <randy.e.witt at linux.intel.com>
> >> >
> >> > This bbclass will create an SDK with a copy of bitbake and the metadata
> >> > and sstate for the target specified for the task. The idea is to let
> >> > "system" developers both work on applications and then test adding them
> >> > to an image without having to switch between workspaces or having to
> >> > download separate items.
> >> >
> >> > Rather than running bitbake directly however, the primary way of running
> >> > builds within the extensible SDK is to use the "devtool" command. The
> >> > rest of the build system is fixed via locked shared state signatures,
> >> > and thus only the recipes you have added get built.
> >> >
> >> > Signed-off-by: Paul Eggleton <paul.eggleton at linux.intel.com>
> >> > Signed-off-by: Randy Witt <randy.e.witt at linux.intel.com>
> >> > Signed-off-by: Chen Qi <Qi.Chen at windriver.com>
> >>
> >> Why another class? it could be tuned using SDKIMAGE_FEATURES
> >
> > If you look at what the class does it would be a bit messy to do it that way -
> > I wanted to get something working with minimal impact. I don't doubt
> > that it could be implemented as an SDKIMAGE_FEATURES item though
> > with extra work.
> 
> As far this does not gets merged I am fine with that. This is clearly
> a WIP code and shouldn't be merged as is.

This code adds in an alternative SDK format and it drives that using a
different task target. Right now its hard for people to see where things
are going, this puts it in easy reach whilst allowing the current SDK to
continue to work too.

I think a choice of two different task targets here makes sense to drive
this configuration rather than SDKIMAGE_FEATURES and I agree with Paul
that adding it the other way would be complex, error prone and
confusing.

Cheers,

Richard