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

[Phil Blundell]

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.  

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.

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. 

p.