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
[email protected]
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
_______________________________________________
Openembedded-core mailing list
[email protected]
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
