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

[Otavio Salvador]

On Mon, Feb 23, 2015 at 3:06 PM, Richard Purdie
<richard.purdie at linuxfoundation.org> wrote:
> 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.

Well so why we don't add populate_sdk+dev-pkgs+dbg-pkgs.

Sorry ... it is clear that people wish this feature (and I also do)
and appreciate the hard work Paul has put on this (yes this is indeed
a good amount of work) but the extra task does not seem to fit how the
system is designed.

The SDKIMAGE_FEATURES[1] is described as:


Equivalent to IMAGE_FEATURES. However, this variable applies to the
SDK generated from an image using the following command:

     $ bitbake -c populate_sdk imagename

and it makes a lot of sense to have a 'extended' or 'devtool' or
another name for this feature.

1. http://www.yoctoproject.org/docs/current/ref-manual/ref-manual.html#var-SDKIMAGE_FEATURES

-- 
Otavio Salvador                             O.S. Systems
http://www.ossystems.com.br        http://code.ossystems.com.br
Mobile: +55 (53) 9981-7854            Mobile: +1 (347) 903-9750