Re: [PATCH 6/6] image.bbclass: Add support to build the SDK in parallel with the image

[Mark Hatle <mark.hatle@windriver.com>]

On 7/2/12 4:05 PM, Phil Blundell wrote:
> On Mon, 2012-07-02 at 15:32 -0500, Mark Hatle wrote:
>> On 7/2/12 3:12 PM, Phil Blundell wrote:
>>> On Sat, 2012-06-30 at 00:07 -0500, Mark Hatle wrote:
>>>> diff --git a/meta/classes/image.bbclass b/meta/classes/image.bbclass
>>>> index 4f50376..7e41982 100644
>>>> --- a/meta/classes/image.bbclass
>>>> +++ b/meta/classes/image.bbclass
>>>> @@ -3,6 +3,11 @@ inherit rootfs_${IMAGE_PKGTYPE}
>>>>    IMAGETEST ?= "dummy"
>>>>    inherit imagetest-${IMAGETEST}
>>>>
>>>> +inherit populate_sdk_base
>>>
>>> This seems to haul a vast amount of stuff into image.bbclass.  Is it
>>> really necessary to have all that in there by default?
>>
>> Yes, in order to build an SDK that matches an image, it is.
>>
>> We need to have all of the code that is needed for both IMAGE and SDK
>> generation.  The SDK code is only active if and only if you call the
>> populate_sdk task.
>
> Can the SDK bits not live in another class which is applied on top of
> the images via BBCLASSEXTEND or some such?  I don't entirely understand
> why this all needs to be in image.bbclass if, as you say, it's inactive
> by default.

In order to build an SDK that matches an images behavior, we need information 
that can only be supplied from an image recipe, and corresponding image.bbclass 
processing.  Once we have that information, then we can generate an SDK.

The SDK code needs to be included into this stream in order to get the 
information for all possible image types, otherwise we'd have to modify each 
image type that you might possibly want an SDK for.  I believe that is 
unreasonable, since if it works for one image type, why shouldn't it work for 
all of them.

The code is not enabled by default, i.e. in the main task order, specifically to 
preserve existing behavior for the majority of users who don't want a matching 
SDK each time they build an image.  (Building an SDK usually involves building 
somewhere around 800-1000 extra tasks, depending on configuration.)

The SDK code is only enabled when the bitbake -c populate_sdk <image recipe> is 
called.  This also avoids all of the standard tasks from the image recipe.

> The code itself looks harmless enough to a casual inspection, but the
> increased number of nested "inherits" does make it rather more difficult
> to understand what's going on, since you have to inspect all of the
> inherited files to understand whether or not they are doing anything.

The image class and populate_sdk_base class are designed to continue to be 
managed and handled separately from a development point of view.  The only 
interconnection is (in image.bbclass) the definiton of:

TOOLCHAIN_TARGET_TASK += "${PACKAGE_INSTALL}"
TOOLCHAIN_TARGET_TASK_ATTEMPTONLY += "${PACKAGE_INSTALL_ATTEMPTONLY} 
${PACKAGE_GROUP_dev-pkgs} ${PACKAGE_GROUP_dbg-pkgs}"

(note: the PACKAGE_GROUP_*, PACKAGE_INSTALL and PACKAGE_INSTALL_ATTEMPTONLY are 
the items that are only known by the image recipe/image.bbclass..)

If you are not using the SDK, the values get set and ignored.

> If we really are going to have this included in image.bbclass, though,
> then it might be worth trying to eliminate the duplicate definitions
> between image.bbclass and populate_sdk{_base}.bbclass.  I think PID and
> EXCLUDE_FROM_WORLD, at least, are defined in both places and I suspect
> there are probably some more.

If these duplications were removed, then the standalone SDKs such as 
meta-toolchain or meta-toolchain-gmae would fail.  By leaving them there, the 
behaviors are kept in sync, those values happen to be the same in both, and it 
allows the SDK to continue to be used separately as it has always been.

We could conceivable remove them from the image.bbclass, but if someone decides 
later to break apart this code -- then they'll have to re-add them to get the 
desired behavior.  I felt it was safer to leave the image and populate_sdk as 
complete as possible.

--Mark

> p.
>
>
>
> _______________________________________________
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
>