Enable the ability to create an image matching SDK

PATCH Superseded Mark Hatle 4 participants 17 messages Jun 30, 2012 – Jul 3, 2012

Share & tools

Mark Hatle

author

2012-06-30 05:09 UTC #0 lore raw

cover Enable the ability to create an image matching SDK

After this series of patches, it is possible to generate an SDK that matches the image. The SDK and all related code is only activated if an image recipe is built using the "populate_sdk" task, such as:

bitbake core-image-sato -c populate_sdk

Existing SDK images, such as meta-toolchain or meta-toolchain-gmae continue to work without modifications.

The following changes since commit 54429dfcca0e35a3aeaa78e509240b87d6a8f4ac:

mklibs-native: Upgrade to 0.1.34 (2012-06-29 13:21:19 +0100)

are available in the git repository at:
git://git.pokylinux.org/poky-contrib mhatle/sdk
http://git.pokylinux.org/cgit.cgi/poky-contrib/log/?h=mhatle/sdk

Mark Hatle (6):
Fix manual log file paths
populate_sdk.bbclass: Split into two parts
populate_sdk: Allow for attempt only packages in the SDK populate_sdk_base.bbclass: Change to using task specific depends
populate_sdk: enable basic multilib support image.bbclass: Add support to build the SDK in parallel with the
image

 meta/classes/image.bbclass             |    7 ++-
 meta/classes/package_deb.bbclass       |    4 +-
 meta/classes/package_ipk.bbclass       |    2 +-
 meta/classes/package_rpm.bbclass       |   10 +-
 meta/classes/populate_sdk.bbclass      |   91 +---------------------
 meta/classes/populate_sdk_base.bbclass |  128 ++++++++++++++++++++++++++++++++
 meta/classes/populate_sdk_deb.bbclass  |    6 +-
 meta/classes/populate_sdk_ipk.bbclass  |    5 +-
 meta/classes/populate_sdk_rpm.bbclass  |    4 +-
 meta/classes/rootfs_deb.bbclass        |    2 +
 meta/classes/rootfs_ipk.bbclass        |    2 +
 meta/classes/toolchain-scripts.bbclass |   16 +++--
 12 files changed, 170 insertions(+), 107 deletions(-)
 create mode 100644 meta/classes/populate_sdk_base.bbclass

Signature · 1 line

1.7.3.4

Mark Hatle

author

2012-06-30 05:09 UTC #1 lore raw

PATCH 1/6 Fix manual log file paths

When a recent change, the path to log files may be contained within an arbitrary directory. To generate the manual log files in the correct path we should be using the ${BB_LOGFILE}'s path instead of always assuming the logs go into ${WORKDIR}/temp.

Signed-off-by Mark Hatle <[email protected]>

---
 meta/classes/image.bbclass        |    2 +-
 meta/classes/package_deb.bbclass  |    4 ++--
 meta/classes/package_ipk.bbclass  |    2 +-
 meta/classes/package_rpm.bbclass  |   10 +++++-----
 meta/classes/populate_sdk.bbclass |    2 +-
 5 files changed, 10 insertions(+), 10 deletions(-)

meta/classes/image.bbclass +1 -1

index 0772363..4f50376 100644
@@ -218,7 +218,7 @@ insert_feed_uris () {
 log_check() {
 	for target in $*
 	do
-		lf_path="${WORKDIR}/temp/log.do_$target.${PID}"
+		lf_path="`dirname ${BB_LOGFILE}`/log.do_$target.${PID}"
 		
 		echo "log_check: Using $lf_path as logfile"

meta/classes/package_deb.bbclass +2 -2

index 0a3e976..cb4bef9 100644
@@ -167,10 +167,10 @@ package_install_internal_deb () {
 		fi
 	done
 
-	rm -f ${WORKDIR}/temp/log.do_${task}-attemptonly.${PID}
+	rm -f `dirname ${BB_LOGFILE}`/log.do_${task}-attemptonly.${PID}
 	if [ ! -z "${package_attemptonly}" ]; then
 		for i in ${package_attemptonly}; do
-			apt-get install $i --force-yes --allow-unauthenticated >> ${WORKDIR}/temp/log.do_${task}-attemptonly.${PID} 2>&1 || true
+			apt-get install $i --force-yes --allow-unauthenticated >> `dirname ${BB_LOGFILE}`/log.do_${task}-attemptonly.${PID} 2>&1 || true
 		done
 	fi

meta/classes/package_ipk.bbclass +1 -1

index c86ea03..e682e6a 100644
@@ -157,7 +157,7 @@ package_install_internal_ipk() {
 	fi
 
 	if [ ! -z "${package_attemptonly}" ]; then
-		opkg-cl ${ipkg_args} install ${package_attemptonly} > "${WORKDIR}/temp/log.do_${task}_attemptonly.${PID}" || true
+		opkg-cl ${ipkg_args} install ${package_attemptonly} > "`dirname ${BB_LOGFILE}`/log.do_${task}_attemptonly.${PID}" || true
 	fi
 
 	package_tryout_install_multilib_ipk

meta/classes/package_rpm.bbclass +5 -5

index 5559a46..ee2285e 100644
@@ -342,14 +342,14 @@ package_install_internal_rpm () {
 				echo "Note: Unable to find package $pkg ($ml_pkg) -- PACKAGE_INSTALL_ATTEMPTONLY"
 				continue
 			fi
-			echo "Attempting $pkg_name..." >> "${WORKDIR}/temp/log.do_${task}_attemptonly.${PID}"
+			echo "Attempting $pkg_name..." >> "`dirname ${BB_LOGFILE}`log.do_${task}_attemptonly.${PID}"
 			${RPM} --predefine "_rpmds_sysinfo_path ${target_rootfs}/etc/rpm/sysinfo" \
 				--predefine "_rpmrc_platform_path ${target_rootfs}/etc/rpm/platform" \
 				--root "${target_rootfs}/install" \
 				-D "_dbpath ${target_rootfs}/install" -D "`cat ${confbase}.macro`" \
 				-D "__dbi_txn create nofsync private" \
 				-U --justdb --noscripts --notriggers --noparentdirs --nolinktos --ignoresize \
-			$pkg_name >> "${WORKDIR}/temp/log.do_${task}_attemptonly.${PID}" || true
+			$pkg_name >> "`dirname ${BB_LOGFILE}`log.do_${task}_attemptonly.${PID}" || true
 		done
 	fi

@@ -390,17 +390,17 @@ package_install_internal_rpm () {
 
 			if [ $found -eq 0 ]; then
 				echo "Note: Unable to find package $pkg -- suggests"
-				echo "Unable to find package $pkg." >> "${WORKDIR}/temp/log.do_${task}_recommend.${PID}"
+				echo "Unable to find package $pkg." >> "`dirname ${BB_LOGFILE}`log.do_${task}_recommend.${PID}"
 				continue
 			fi
-			echo "Attempting $pkg_name..." >> "${WORKDIR}/temp/log.do_{task}_recommend.${PID}"
+			echo "Attempting $pkg_name..." >> "`dirname ${BB_LOGFILE}`log.do_{task}_recommend.${PID}"
 			${RPM} --predefine "_rpmds_sysinfo_path ${target_rootfs}/etc/rpm/sysinfo" \
 				--predefine "_rpmrc_platform_path ${target_rootfs}/etc/rpm/platform" \
 				--root "${target_rootfs}/install" \
 				-D "_dbpath ${target_rootfs}/install" -D "`cat ${confbase}.macro`" \
 				-D "__dbi_txn create nofsync private" \
 				-U --justdb --noscripts --notriggers --noparentdirs --nolinktos --ignoresize \
-				$pkg_name >> "${WORKDIR}/temp/log.do_${task}_recommend.${PID}" 2>&1 || true
+				$pkg_name >> "`dirname ${BB_LOGFILE}`log.do_${task}_recommend.${PID}" 2>&1 || true
 		done
 		cat ${target_rootfs}/install/recommend.list ${target_rootfs}/install/recommend.new | sort -u > ${target_rootfs}/install/recommend.new.list
 		mv -f ${target_rootfs}/install/recommend.new.list ${target_rootfs}/install/recommend.list

meta/classes/populate_sdk.bbclass +1 -1

index 5aa8e92..1131d68 100644
@@ -70,7 +70,7 @@ fakeroot do_populate_sdk() {
 populate_sdk_log_check() {
 	for target in $*
 	do
-		lf_path="${WORKDIR}/temp/log.do_$target.${PID}"
+		lf_path="`dirname ${BB_LOGFILE}`/log.do_$target.${PID}"
 
 		echo "log_check: Using $lf_path as logfile"

Signature · 1 line

1.7.3.4

Mark Hatle

author

2012-06-30 05:09 UTC #2 lore raw

PATCH 2/6 populate_sdk.bbclass: Split into two parts

In reply to Mark Hatle

populate_sdk was renamed to populate_sdk_base in order to allow for changes that may break existing SDK recipes. Any such changes need an analog in populate_sdk (new version) to restore previous desired behavior.

In addition to the rename, one minor change was made. The _base version only had the do_populate_sdk as an added task, but no before or after defined.

For compatibility, populate_sdk has do_populate_sdk defined as "after" do_install and before do_build, this is identical to the original behavior.

Signed-off-by Mark Hatle <[email protected]>

---
 meta/classes/populate_sdk.bbclass      |   91 ++------------------------------
 meta/classes/populate_sdk_base.bbclass |   89 +++++++++++++++++++++++++++++++
 2 files changed, 93 insertions(+), 87 deletions(-)
 create mode 100644 meta/classes/populate_sdk_base.bbclass

meta/classes/populate_sdk.bbclass +4 ~~-87~~

index 1131d68..e5bb540 100644
@@ -1,89 +1,6 @@
-inherit meta toolchain-scripts
-inherit populate_sdk_${IMAGE_PKGTYPE}
+# The majority of populate_sdk is located in populate_sdk_base
+# This chunk simply facilitates compatibility with SDK only recipes.
 
-SDK_DIR = "${WORKDIR}/sdk"
-SDK_OUTPUT = "${SDK_DIR}/image"
-SDK_DEPLOY = "${TMPDIR}/deploy/sdk"
+inherit populate_sdk_base
 
-SDKTARGETSYSROOT = "${SDKPATH}/sysroots/${MULTIMACH_TARGET_SYS}"
-
-TOOLCHAIN_HOST_TASK ?= "task-sdk-host-nativesdk task-cross-canadian-${TRANSLATED_TARGET_ARCH}"
-TOOLCHAIN_TARGET_TASK ?= "task-core-standalone-sdk-target task-core-standalone-sdk-target-dbg"
-TOOLCHAIN_OUTPUTNAME ?= "${SDK_NAME}-toolchain-${DISTRO_VERSION}"
-
-RDEPENDS = "${TOOLCHAIN_TARGET_TASK} ${TOOLCHAIN_HOST_TASK}"
-DEPENDS = "virtual/fakeroot-native sed-native"
-
-PID = "${@os.getpid()}"
-
-EXCLUDE_FROM_WORLD = "1"
-
-python () {
-    # If we don't do this we try and run the mapping hooks while parsing which is slow
-    # bitbake should really provide something to let us know this...
-    if bb.data.getVar('BB_WORKERCONTEXT', d, True) is not None:
-        runtime_mapping_rename("TOOLCHAIN_TARGET_TASK", d)
-}
-
-fakeroot do_populate_sdk() {
-	rm -rf ${SDK_OUTPUT}
-	mkdir -p ${SDK_OUTPUT}
-
-	# populate_sdk_<image> is required to construct two images:
-	#  SDK_ARCH-nativesdk - contains the cross compiler and associated tooling
-	#  target - contains a target rootfs configured for the SDK usage
-	#
-	# the output of populate_sdk_<image> should end up in ${SDK_OUTPUT} it is made
-	# up of:
-	#  ${SDK_OUTPUT}/<sdk_arch-nativesdk pkgs>
-	#  ${SDK_OUTPUT}/${SDKTARGETSYSROOT}/<target pkgs>
-
-	populate_sdk_${IMAGE_PKGTYPE}
-
-	# Don't ship any libGL in the SDK
-	rm -rf ${SDK_OUTPUT}/${SDKPATHNATIVE}${libdir_nativesdk}/libGL*
-
-	# Can copy pstage files here
-	# target_pkgs=`cat ${SDK_OUTPUT}/${SDKTARGETSYSROOT}/var/lib/opkg/status | grep Package: | cut -f 2 -d ' '`
-
-	# Fix or remove broken .la files
-	#rm -f ${SDK_OUTPUT}/${SDKPATHNATIVE}/lib/*.la
-	rm -f ${SDK_OUTPUT}/${SDKPATHNATIVE}${libdir_nativesdk}/*.la
-
-	# Link the ld.so.cache file into the hosts filesystem
-	ln -s /etc/ld.so.cache ${SDK_OUTPUT}/${SDKPATHNATIVE}/etc/ld.so.cache
-
-	# Setup site file for external use
-	toolchain_create_sdk_siteconfig ${SDK_OUTPUT}/${SDKPATH}/site-config-${MULTIMACH_TARGET_SYS}
-
-	toolchain_create_sdk_env_script
-
-	# Add version information
-	toolchain_create_sdk_version ${SDK_OUTPUT}/${SDKPATH}/version-${MULTIMACH_TARGET_SYS}
-
-	# Package it up
-	mkdir -p ${SDK_DEPLOY}
-	cd ${SDK_OUTPUT}
-	tar --owner=root --group=root -cj --file=${SDK_DEPLOY}/${TOOLCHAIN_OUTPUTNAME}.tar.bz2 .
-}
-
-populate_sdk_log_check() {
-	for target in $*
-	do
-		lf_path="`dirname ${BB_LOGFILE}`/log.do_$target.${PID}"
-
-		echo "log_check: Using $lf_path as logfile"
-
-		if test -e "$lf_path"
-		then
-			${IMAGE_PKGTYPE}_log_check $target $lf_path
-		else
-			echo "Cannot find logfile [$lf_path]"
-		fi
-		echo "Logfile is clean"
-	done
-}
-
-do_populate_sdk[nostamp] = "1"
-do_populate_sdk[recrdeptask] = "do_package_write"
-addtask populate_sdk before do_build after do_install
+addtask populate_sdk after do_install before do_build

meta/classes/populate_sdk_base.bbclass new file +89 -0

89 lines not on this page · raw message

Signature · 1 line

1.7.3.4

Mark Hatle

author

2012-06-30 05:09 UTC #3 lore raw

PATCH 3/6 populate_sdk: Allow for attempt only packages in the SDK

In reply to Mark Hatle

We want to be able to supply attempt only packages in the SDK in order to support more advanced SDK images that more closely match specific image recipes.

Signed-off-by Mark Hatle <[email protected]>

---
 meta/classes/populate_sdk_base.bbclass |    2 ++
 meta/classes/populate_sdk_deb.bbclass  |    4 ++--
 meta/classes/populate_sdk_ipk.bbclass  |    3 ++-
 meta/classes/populate_sdk_rpm.bbclass  |    4 ++--
 4 files changed, 8 insertions(+), 5 deletions(-)

meta/classes/populate_sdk_base.bbclass +2 -0

index a3bf8c2..a0a0a80 100644
@@ -8,7 +8,9 @@ SDK_DEPLOY = "${TMPDIR}/deploy/sdk"
 SDKTARGETSYSROOT = "${SDKPATH}/sysroots/${MULTIMACH_TARGET_SYS}"
 
 TOOLCHAIN_HOST_TASK ?= "task-sdk-host-nativesdk task-cross-canadian-${TRANSLATED_TARGET_ARCH}"
+TOOLCHAIN_HOST_TASK_ATTEMPTONLY ?= ""
 TOOLCHAIN_TARGET_TASK ?= "task-core-standalone-sdk-target task-core-standalone-sdk-target-dbg"
+TOOLCHAIN_TARGET_TASK_ATTEMPTONLY ?= ""
 TOOLCHAIN_OUTPUTNAME ?= "${SDK_NAME}-toolchain-${DISTRO_VERSION}"
 
 RDEPENDS = "${TOOLCHAIN_TARGET_TASK} ${TOOLCHAIN_HOST_TASK}"

meta/classes/populate_sdk_deb.bbclass +2 -2

index 920c89a..c3b3e0c 100644
@@ -28,7 +28,7 @@ populate_sdk_deb () {
 	export INSTALL_BASEARCH_DEB="${DPKG_ARCH}"
 	export INSTALL_ARCHS_DEB="${PACKAGE_ARCHS}"
 	export INSTALL_PACKAGES_DEB="${TOOLCHAIN_TARGET_TASK}"
-	export INSTALL_PACKAGES_ATTEMPTONLY_DEB=""
+	export INSTALL_PACKAGES_ATTEMPTONLY_DEB="${TOOLCHAIN_TARGET_TASK_ATTEMPTONLY}"
 	export PACKAGES_LINGUAS_DEB=""
 	export INSTALL_TASK_DEB="populate_sdk-target"

@@ -44,7 +44,7 @@ populate_sdk_deb () {
 	export INSTALL_BASEARCH_DEB="${DEB_SDK_ARCH}"
 	export INSTALL_ARCHS_DEB="${SDK_PACKAGE_ARCHS}"
 	export INSTALL_PACKAGES_DEB="${TOOLCHAIN_HOST_TASK}"
-	export INSTALL_PACKAGES_ATTEMPTONLY_DEB=""
+	export INSTALL_PACKAGES_ATTEMPTONLY_DEB="${TOOLCHAIN_HOST_TASK_ATTEMPTONLY}"
 	export PACKAGES_LINGUAS_DEB=""
 	export INSTALL_TASK_DEB="populate_sdk-nativesdk"

meta/classes/populate_sdk_ipk.bbclass +2 -1

index c256c69..aa3efde 100644
@@ -11,7 +11,6 @@ populate_sdk_ipk() {
 	package_update_index_ipk
 	package_generate_ipkg_conf
 
-	export INSTALL_PACKAGES_ATTEMPTONLY_IPK=""
 	export INSTALL_PACKAGES_LINGUAS_IPK=""
 	export INSTALL_TASK_IPK="populate_sdk"

@@ -19,6 +18,7 @@ populate_sdk_ipk() {
 	export INSTALL_ROOTFS_IPK="${SDK_OUTPUT}/${SDKTARGETSYSROOT}"
 	export INSTALL_CONF_IPK="${IPKGCONF_TARGET}"
 	export INSTALL_PACKAGES_IPK="${TOOLCHAIN_TARGET_TASK}"
+	export INSTALL_PACKAGES_ATTEMPTONLY_IPK="${TOOLCHAIN_TARGET_TASK_ATTEMPTONLY}"
 
 	export D=${INSTALL_ROOTFS_IPK}
 	export OFFLINE_ROOT=${INSTALL_ROOTFS_IPK}

@@ -31,6 +31,7 @@ populate_sdk_ipk() {
 	export INSTALL_ROOTFS_IPK="${SDK_OUTPUT}"
 	export INSTALL_CONF_IPK="${IPKGCONF_SDK}"
 	export INSTALL_PACKAGES_IPK="${TOOLCHAIN_HOST_TASK}"
+	export INSTALL_PACKAGES_ATTEMPTONLY_IPK="${TOOLCHAIN_HOST_TASK_ATTEMPTONLY}"
 
 	package_install_internal_ipk

meta/classes/populate_sdk_rpm.bbclass +2 -2

index e0adb8f..b115c27 100644
@@ -33,7 +33,7 @@ populate_sdk_rpm () {
 	export INSTALL_PLATFORM_RPM="${TARGET_ARCH}"
 	export INSTALL_CONFBASE_RPM="${RPMCONF_TARGET_BASE}"
 	export INSTALL_PACKAGES_RPM="${TOOLCHAIN_TARGET_TASK}"
-	export INSTALL_PACKAGES_ATTEMPTONLY_RPM=""
+	export INSTALL_PACKAGES_ATTEMPTONLY_RPM="${TOOLCHAIN_TARGET_TASK_ATTEMPTONLY}"
 	export INSTALL_PACKAGES_LINGUAS_RPM=""
 	export INSTALL_PROVIDENAME_RPM="/bin/sh /bin/bash /usr/bin/env /usr/bin/perl pkgconfig pkgconfig(pkg-config)"
 	export INSTALL_TASK_RPM="populate_sdk-target"

@@ -82,7 +82,7 @@ EOF
 	export INSTALL_PLATFORM_RPM="${SDK_ARCH}"
 	export INSTALL_CONFBASE_RPM="${RPMCONF_HOST_BASE}"
 	export INSTALL_PACKAGES_RPM="${TOOLCHAIN_HOST_TASK}"
-	export INSTALL_PACKAGES_ATTEMPTONLY_RPM=""
+	export INSTALL_PACKAGES_ATTEMPTONLY_RPM="${TOOLCHAIN_TARGET_HOST_ATTEMPTONLY}"
 	export INSTALL_PACKAGES_LINGUAS_RPM=""
 	export INSTALL_PROVIDENAME_RPM="/bin/sh /bin/bash /usr/bin/env /usr/bin/perl pkgconfig libGL.so()(64bit) libGL.so"
 	export INSTALL_TASK_RPM="populate_sdk_rpm-nativesdk"

Signature · 1 line

1.7.3.4

Mark Hatle

author

2012-06-30 05:09 UTC #4 lore raw

PATCH 4/6 populate_sdk_base.bbclass: Change to using task specific depends

In reply to Mark Hatle

If we combine the do_populate_sdk with the image generation, we want to avoid the dependency processing unless do_populate_sdk is run.

This requires the bitbake change to implement task based rdepends.

Signed-off-by Mark Hatle <[email protected]>

---
 meta/classes/populate_sdk_base.bbclass |    6 ++++--
 1 files changed, 4 insertions(+), 2 deletions(-)

meta/classes/populate_sdk_base.bbclass +4 -2

index a0a0a80..6508bd9 100644
@@ -13,8 +13,8 @@ TOOLCHAIN_TARGET_TASK ?= "task-core-standalone-sdk-target task-core-standalone-s
 TOOLCHAIN_TARGET_TASK_ATTEMPTONLY ?= ""
 TOOLCHAIN_OUTPUTNAME ?= "${SDK_NAME}-toolchain-${DISTRO_VERSION}"
 
-RDEPENDS = "${TOOLCHAIN_TARGET_TASK} ${TOOLCHAIN_HOST_TASK}"
-DEPENDS = "virtual/fakeroot-native sed-native"
+SDK_RDEPENDS = "${TOOLCHAIN_TARGET_TASK} ${TOOLCHAIN_HOST_TASK}"
+SDK_DEPENDS = "virtual/fakeroot-native sed-native"
 
 PID = "${@os.getpid()}"

@@ -87,5 +87,7 @@ populate_sdk_log_check() {
 }
 
 do_populate_sdk[nostamp] = "1"
+do_populate_sdk[depends] = "${@' '.join([x + ':do_populate_sysroot' for x in d.getVar('SDK_DEPENDS', True).split()])}"
+do_populate_sdk[rdepends] = "${@' '.join([x + ':do_populate_sysroot' for x in d.getVar('SDK_RDEPENDS', True).split()])}"
 do_populate_sdk[recrdeptask] = "do_package_write"
 addtask populate_sdk

Signature · 1 line

1.7.3.4

Mark Hatle

author

2012-06-30 05:09 UTC #5 lore raw

PATCH 5/6 populate_sdk: enable basic multilib support

In reply to Mark Hatle

In order to enable basic multilib support for the export of an SDK image, a number of minor changes had to be made:

The value of MULTIMACH_TARGET_SYS needs to be variable. This way we can define the value to the appropriate multilib. (Also in some cases the default PACKAGE_ARCH is set to MACHINE_ARCH which is incorrect for the SDK.) Add a companion REAL_MULTIMACH_TARGET_SYS, based on code from meta-environment, to allow for this.

We have to convert the do_populate_sdk into a python call, and then break up the previous items into three parts.
* Image construction
* Setup of environment files
* Generation of the tarball

Then we can iterate over the multilibs to populate the environment files.

Finally, matching changes were needed in the toolchain-scripts file. And what I presume is an optimization of immediate evaluation for TOOLCHAIN_CONFIGSITE_NOCACHE and ..._SYSROOTCACHE needed to be done at runtime, otherwise the wrong values may be used.

Signed-off-by Mark Hatle <[email protected]>

---
 meta/classes/populate_sdk_base.bbclass |   42 ++++++++++++++++++++++++++++---
 meta/classes/toolchain-scripts.bbclass |   16 +++++++----
 2 files changed, 48 insertions(+), 10 deletions(-)

meta/classes/populate_sdk_base.bbclass +38 -4

index 6508bd9..6dc66fb 100644
@@ -16,6 +16,10 @@ TOOLCHAIN_OUTPUTNAME ?= "${SDK_NAME}-toolchain-${DISTRO_VERSION}"
 SDK_RDEPENDS = "${TOOLCHAIN_TARGET_TASK} ${TOOLCHAIN_HOST_TASK}"
 SDK_DEPENDS = "virtual/fakeroot-native sed-native"
 
+# We want the MULTIARCH_TARGET_SYS to point to the TUNE_PKGARCH, not PACKAGE_ARCH as it
+# could be set to the MACHINE_ARCH
+REAL_MULTIMACH_TARGET_SYS = "${TUNE_PKGARCH}${TARGET_VENDOR}-${TARGET_OS}"
+
 PID = "${@os.getpid()}"
 
 EXCLUDE_FROM_WORLD = "1"

@@ -27,7 +31,33 @@ python () {
         runtime_mapping_rename("TOOLCHAIN_TARGET_TASK", d)
 }
 
-fakeroot do_populate_sdk() {
+fakeroot python do_populate_sdk() {
+	bb.build.exec_func("populate_sdk_image", d)
+
+	# Handle multilibs in the SDK environment, siteconfig, etc files...
+	localdata = bb.data.createCopy(d)
+
+	# make sure we only use the WORKDIR value from 'd', or it can change
+	localdata.setVar('WORKDIR', d.getVar('WORKDIR', True))
+
+	# make sure we only use the SDKTARGETSYSROOT value from 'd'
+	localdata.setVar('SDKTARGETSYSROOT', d.getVar('SDKTARGETSYSROOT', True))
+
+	# Process DEFAULTTUNE
+	bb.build.exec_func("create_sdk_files", localdata)
+
+	variants = d.getVar("MULTILIB_VARIANTS", True) or ""
+	for item in variants.split():
+		# Load overrides from 'd' to avoid having to reset the value...
+		overrides = d.getVar("OVERRIDES", False) + ":virtclass-multilib-" + item
+		localdata.setVar("OVERRIDES", overrides)
+		bb.data.update_data(localdata)
+		bb.build.exec_func("create_sdk_files", localdata)
+
+	bb.build.exec_func("tar_sdk", d)
+}
+
+fakeroot populate_sdk_image() {
 	rm -rf ${SDK_OUTPUT}
 	mkdir -p ${SDK_OUTPUT}

@@ -54,15 +84,19 @@ fakeroot do_populate_sdk() {
 
 	# Link the ld.so.cache file into the hosts filesystem
 	ln -s /etc/ld.so.cache ${SDK_OUTPUT}/${SDKPATHNATIVE}/etc/ld.so.cache
+}
 
+fakeroot create_sdk_files() {
 	# Setup site file for external use
-	toolchain_create_sdk_siteconfig ${SDK_OUTPUT}/${SDKPATH}/site-config-${MULTIMACH_TARGET_SYS}
+	toolchain_create_sdk_siteconfig ${SDK_OUTPUT}/${SDKPATH}/site-config-${REAL_MULTIMACH_TARGET_SYS}
 
-	toolchain_create_sdk_env_script
+	toolchain_create_sdk_env_script ${SDK_OUTPUT}/${SDKPATH}/environment-setup-${REAL_MULTIMACH_TARGET_SYS}
 
 	# Add version information
-	toolchain_create_sdk_version ${SDK_OUTPUT}/${SDKPATH}/version-${MULTIMACH_TARGET_SYS}
+	toolchain_create_sdk_version ${SDK_OUTPUT}/${SDKPATH}/version-${REAL_MULTIMACH_TARGET_SYS}
+}
 
+fakeroot tar_sdk() {
 	# Package it up
 	mkdir -p ${SDK_DEPLOY}
 	cd ${SDK_OUTPUT}

meta/classes/toolchain-scripts.bbclass +10 -6

index 2099c4d..bedcd61 100644
@@ -1,15 +1,19 @@
 inherit siteinfo
 
+# We want to be able to change the value of MULTIMACH_TARGET_SYS, because it
+# doesn't always match our expectations... but we default to the stock value
+REAL_MULTIMACH_TARGET_SYS ?= "${MULTIMACH_TARGET_SYS}"
+
 # This function creates an environment-setup-script for use in a deployable SDK
 toolchain_create_sdk_env_script () {
 	# Create environment setup script
-	script=${SDK_OUTPUT}/${SDKPATH}/environment-setup-${MULTIMACH_TARGET_SYS}
+	script=${1:-${SDK_OUTPUT}/${SDKPATH}/environment-setup-${REAL_MULTIMACH_TARGET_SYS}}
 	rm -f $script
 	touch $script
-	echo 'export PATH=${SDKPATHNATIVE}${bindir_nativesdk}:${SDKPATHNATIVE}${bindir_nativesdk}/${MULTIMACH_TARGET_SYS}:$PATH' >> $script
+	echo 'export PATH=${SDKPATHNATIVE}${bindir_nativesdk}:${SDKPATHNATIVE}${bindir_nativesdk}/${REAL_MULTIMACH_TARGET_SYS}:$PATH' >> $script
 	echo 'export PKG_CONFIG_SYSROOT_DIR=${SDKTARGETSYSROOT}' >> $script
 	echo 'export PKG_CONFIG_PATH=${SDKTARGETSYSROOT}${libdir}/pkgconfig' >> $script
-	echo 'export CONFIG_SITE=${SDKPATH}/site-config-${MULTIMACH_TARGET_SYS}' >> $script
+	echo 'export CONFIG_SITE=${SDKPATH}/site-config-${REAL_MULTIMACH_TARGET_SYS}' >> $script
 	echo 'export CC=${TARGET_PREFIX}gcc' >> $script
 	echo 'export CXX=${TARGET_PREFIX}g++' >> $script
 	echo 'export GDB=${TARGET_PREFIX}gdb' >> $script

@@ -36,7 +40,7 @@ toolchain_create_sdk_env_script () {
 # This function creates an environment-setup-script in the TMPDIR which enables
 # a OE-core IDE to integrate with the build tree
 toolchain_create_tree_env_script () {
-	script=${TMPDIR}/environment-setup-${MULTIMACH_TARGET_SYS}
+	script=${TMPDIR}/environment-setup-${REAL_MULTIMACH_TARGET_SYS}
 	rm -f $script
 	touch $script
 	echo 'export PATH=${PATH}' >> $script

@@ -103,8 +107,8 @@ toolchain_create_sdk_env_script_for_installer () {
 }
 
 #we get the cached site config in the runtime
-TOOLCHAIN_CONFIGSITE_NOCACHE := "${@siteinfo_get_files(d, True)}"
-TOOLCHAIN_CONFIGSITE_SYSROOTCACHE := "${STAGING_DATADIR}/${TARGET_SYS}_config_site.d"
+TOOLCHAIN_CONFIGSITE_NOCACHE = "${@siteinfo_get_files(d, True)}"
+TOOLCHAIN_CONFIGSITE_SYSROOTCACHE = "${STAGING_DATADIR}/${TARGET_SYS}_config_site.d"
 TOOLCHAIN_NEED_CONFIGSITE_CACHE = "${TCLIBC} ncurses"
 
 #This function create a site config file

Signature · 1 line

1.7.3.4

Mark Hatle

author

2012-06-30 05:09 UTC #6 lore raw

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

In reply to Mark Hatle

When building an image recipe, you can now build a companion SDK by calling the populate_sdk task:
bitbake -c populate_sdk core-image-minimal

Note: there are still issues w/ the SDK not working completely with multilibs.

A lock is required between rootfs and populate_sdk activities to prevent configuration file clashes and similar package management problems in ipk and deb based systems. (RPM already had a lock for a different reason.)

Signed-off-by Mark Hatle <[email protected]>

---
 meta/classes/image.bbclass             |    5 +++++
 meta/classes/populate_sdk_base.bbclass |    1 +
 meta/classes/populate_sdk_deb.bbclass  |    2 ++
 meta/classes/populate_sdk_ipk.bbclass  |    2 ++
 meta/classes/rootfs_deb.bbclass        |    2 ++
 meta/classes/rootfs_ipk.bbclass        |    2 ++
 6 files changed, 14 insertions(+), 0 deletions(-)

meta/classes/image.bbclass +5 -0

index 4f50376..7e41982 100644
@@ -3,6 +3,11 @@ inherit rootfs_${IMAGE_PKGTYPE}
 IMAGETEST ?= "dummy"
 inherit imagetest-${IMAGETEST}
 
+inherit populate_sdk_base
+
+TOOLCHAIN_TARGET_TASK += "${PACKAGE_INSTALL}"
+TOOLCHAIN_TARGET_TASK_ATTEMPTONLY += "${PACKAGE_INSTALL_ATTEMPTONLY} ${PACKAGE_GROUP_dev-pkgs} ${PACKAGE_GROUP_dbg-pkgs}"
+
 inherit gzipnative
 
 LICENSE = "MIT"

meta/classes/populate_sdk_base.bbclass +1 -0

index 6dc66fb..ed2dca0 100644
@@ -120,6 +120,7 @@ populate_sdk_log_check() {
 	done
 }
 
+do_populate_sdk[dirs] = "${TOPDIR}"
 do_populate_sdk[nostamp] = "1"
 do_populate_sdk[depends] = "${@' '.join([x + ':do_populate_sysroot' for x in d.getVar('SDK_DEPENDS', True).split()])}"
 do_populate_sdk[rdepends] = "${@' '.join([x + ':do_populate_sysroot' for x in d.getVar('SDK_RDEPENDS', True).split()])}"

meta/classes/populate_sdk_deb.bbclass +2 -0

index c3b3e0c..9e9e1e1 100644
@@ -6,6 +6,8 @@ DEB_SDK_ARCH = "${@[d.getVar('SDK_ARCH', True), "i386"]\
                 [d.getVar('SDK_ARCH', True) in \
                 ["x86", "i486", "i586", "i686", "pentium"]]}"
 
+do_populate_sdk[lockfiles] += "${WORKDIR}/deb.lock"
+
 populate_sdk_post_deb () {
 
 	local target_rootfs=$1

meta/classes/populate_sdk_ipk.bbclass +2 -0

index aa3efde..4321afb 100644
@@ -1,6 +1,8 @@
 do_populate_sdk[depends] += "opkg-native:do_populate_sysroot opkg-utils-native:do_populate_sysroot"
 do_populate_sdk[recrdeptask] += "do_package_write_ipk"
 
+do_populate_sdk[lockfiles] += "${WORKDIR}/ipk.lock"
+
 populate_sdk_ipk() {
 
 	rm -f ${IPKGCONF_TARGET}

meta/classes/rootfs_deb.bbclass +2 -0

index 6c9767f..4ea71da 100644
@@ -8,6 +8,8 @@ ROOTFS_PKGMANAGE_BOOTSTRAP  = "run-postinsts"
 do_rootfs[depends] += "dpkg-native:do_populate_sysroot apt-native:do_populate_sysroot"
 do_rootfs[recrdeptask] += "do_package_write_deb"
 
+do_rootfs[lockfiles] += "${WORKDIR}/deb.lock"
+
 DEB_POSTPROCESS_COMMANDS = "rootfs_install_all_locales; "
 
 opkglibdir = "${localstatedir}/lib/opkg"

meta/classes/rootfs_ipk.bbclass +2 -0

index 1580086..9732385 100644
@@ -12,6 +12,8 @@ ROOTFS_PKGMANAGE_BOOTSTRAP  = "run-postinsts"
 do_rootfs[depends] += "opkg-native:do_populate_sysroot opkg-utils-native:do_populate_sysroot"
 do_rootfs[recrdeptask] += "do_package_write_ipk"
 
+do_rootfs[lockfiles] += "${WORKDIR}/ipk.lock"
+
 IPKG_ARGS = "-f ${IPKGCONF_TARGET} -o ${IMAGE_ROOTFS} --force-overwrite"
 
 OPKG_PREPROCESS_COMMANDS = "package_update_index_ipk; package_generate_ipkg_conf"

Signature · 1 line

1.7.3.4

Saul Wold

2012-07-02 19:55 UTC #7 lore raw

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

Quoted 11 lines · Mark Hatle

When building an image recipe, you can now build a companion SDK by calling the populate_sdk task:
bitbake -c populate_sdk core-image-minimal
Note: there are still issues w/ the SDK not working completely with multilibs.
A lock is required between rootfs and populate_sdk activities to prevent configuration file clashes and similar package management problems in ipk and deb based systems. (RPM already had a lock for a different reason.)

Mark this seems to have broken non-gplv3 builds. I get the following error now:

Quoted 11 lines

NOTE: Resolving any missing task queue dependencies
ERROR: Nothing RPROVIDES 'binutils-cross-canadian-i586' (but /intel/poky/distro/meta/recipes-core/tasks/task-cross-canadian.bb RDEPENDS on or otherwise requires it)
ERROR: binutils-cross-canadian-i586 was skipped: incompatible with license GPLv3
NOTE: Runtime target 'binutils-cross-canadian-i586' is unbuildable, removing...
Missing or unbuildable dependency chain was: ['binutils-cross-canadian-i586']
NOTE: Runtime target 'task-cross-canadian-i586' is unbuildable, removing...
Missing or unbuildable dependency chain was: ['task-cross-canadian-i586', 'binutils-cross-canadian-i586']
ERROR: Required build target 'core-image-minimal' has no buildable providers.
Missing or unbuildable dependency chain was: ['core-image-minimal', 'task-cross-canadian-i586', 'binutils-cross-canadian-i586']
Summary: There were 2 ERROR messages shown, returning a non-zero exit code.

I am going to hold off on this patch set until this is resolved.

Thanks

Sau!

Quoted 90 lines

Signed-off-by Mark Hatle<[email protected]>

---
  meta/classes/image.bbclass             |    5 +++++
  meta/classes/populate_sdk_base.bbclass |    1 +
  meta/classes/populate_sdk_deb.bbclass  |    2 ++
  meta/classes/populate_sdk_ipk.bbclass  |    2 ++
  meta/classes/rootfs_deb.bbclass        |    2 ++
  meta/classes/rootfs_ipk.bbclass        |    2 ++
  6 files changed, 14 insertions(+), 0 deletions(-)

meta/classes/image.bbclass +5 -0

index 4f50376..7e41982 100644
@@ -3,6 +3,11 @@ inherit rootfs_${IMAGE_PKGTYPE}
  IMAGETEST ?= "dummy"
  inherit imagetest-${IMAGETEST}
 
+inherit populate_sdk_base
+
+TOOLCHAIN_TARGET_TASK += "${PACKAGE_INSTALL}"
+TOOLCHAIN_TARGET_TASK_ATTEMPTONLY += "${PACKAGE_INSTALL_ATTEMPTONLY} ${PACKAGE_GROUP_dev-pkgs} ${PACKAGE_GROUP_dbg-pkgs}"
+
  inherit gzipnative
 
  LICENSE = "MIT"

meta/classes/populate_sdk_base.bbclass +1 -0

index 6dc66fb..ed2dca0 100644
@@ -120,6 +120,7 @@ populate_sdk_log_check() {
  	done
  }
 
+do_populate_sdk[dirs] = "${TOPDIR}"
  do_populate_sdk[nostamp] = "1"
  do_populate_sdk[depends] = "${@' '.join([x + ':do_populate_sysroot' for x in d.getVar('SDK_DEPENDS', True).split()])}"
  do_populate_sdk[rdepends] = "${@' '.join([x + ':do_populate_sysroot' for x in d.getVar('SDK_RDEPENDS', True).split()])}"

meta/classes/populate_sdk_deb.bbclass +2 -0

index c3b3e0c..9e9e1e1 100644
@@ -6,6 +6,8 @@ DEB_SDK_ARCH = "${@[d.getVar('SDK_ARCH', True), "i386"]\
                  [d.getVar('SDK_ARCH', True) in \
                  ["x86", "i486", "i586", "i686", "pentium"]]}"
 
+do_populate_sdk[lockfiles] += "${WORKDIR}/deb.lock"
+
  populate_sdk_post_deb () {
 
  	local target_rootfs=$1

meta/classes/populate_sdk_ipk.bbclass +2 -0

index aa3efde..4321afb 100644
@@ -1,6 +1,8 @@
  do_populate_sdk[depends] += "opkg-native:do_populate_sysroot opkg-utils-native:do_populate_sysroot"
  do_populate_sdk[recrdeptask] += "do_package_write_ipk"
 
+do_populate_sdk[lockfiles] += "${WORKDIR}/ipk.lock"
+
  populate_sdk_ipk() {
 
  	rm -f ${IPKGCONF_TARGET}

meta/classes/rootfs_deb.bbclass +2 -0

index 6c9767f..4ea71da 100644
@@ -8,6 +8,8 @@ ROOTFS_PKGMANAGE_BOOTSTRAP  = "run-postinsts"
  do_rootfs[depends] += "dpkg-native:do_populate_sysroot apt-native:do_populate_sysroot"
  do_rootfs[recrdeptask] += "do_package_write_deb"
 
+do_rootfs[lockfiles] += "${WORKDIR}/deb.lock"
+
  DEB_POSTPROCESS_COMMANDS = "rootfs_install_all_locales; "
 
  opkglibdir = "${localstatedir}/lib/opkg"

meta/classes/rootfs_ipk.bbclass +2 -0

index 1580086..9732385 100644
@@ -12,6 +12,8 @@ ROOTFS_PKGMANAGE_BOOTSTRAP  = "run-postinsts"
  do_rootfs[depends] += "opkg-native:do_populate_sysroot opkg-utils-native:do_populate_sysroot"
  do_rootfs[recrdeptask] += "do_package_write_ipk"
 
+do_rootfs[lockfiles] += "${WORKDIR}/ipk.lock"
+
  IPKG_ARGS = "-f ${IPKGCONF_TARGET} -o ${IMAGE_ROOTFS} --force-overwrite"
 
  OPKG_PREPROCESS_COMMANDS = "package_update_index_ipk; package_generate_ipkg_conf"

Mark Hatle

author

2012-07-02 20:00 UTC #8 lore raw

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

Quoted 8 lines · Saul Wold

Quoted 7 lines · Mark Hatle
When building an image recipe, you can now build a companion SDK by calling the populate_sdk task:
bitbake -c populate_sdk core-image-minimal
Note: there are still issues w/ the SDK not working completely with multilibs.

Quoted 19 lines

Quoted 4 lines
A lock is required between rootfs and populate_sdk activities to prevent configuration file clashes and similar package management problems in ipk and deb based systems. (RPM already had a lock for a different reason.)
Mark this seems to have broken non-gplv3 builds. I get the following error now:
Quoted 11 lines
NOTE: Resolving any missing task queue dependencies
ERROR: Nothing RPROVIDES 'binutils-cross-canadian-i586' (but /intel/poky/distro/meta/recipes-core/tasks/task-cross-canadian.bb RDEPENDS on or otherwise requires it)
ERROR: binutils-cross-canadian-i586 was skipped: incompatible with license GPLv3
NOTE: Runtime target 'binutils-cross-canadian-i586' is unbuildable, removing...
Missing or unbuildable dependency chain was: ['binutils-cross-canadian-i586']
NOTE: Runtime target 'task-cross-canadian-i586' is unbuildable, removing...
Missing or unbuildable dependency chain was: ['task-cross-canadian-i586', 'binutils-cross-canadian-i586']
ERROR: Required build target 'core-image-minimal' has no buildable providers.
Missing or unbuildable dependency chain was: ['core-image-minimal', 'task-cross-canadian-i586', 'binutils-cross-canadian-i586']
Summary: There were 2 ERROR messages shown, returning a non-zero exit code.

As far as I know, this didn't work before either. If you are running:

bitbake core-image-minimal (or similar) it should work -exactly- as it did before, it's only if you add the -c .... that it will change.

I forgot to mention, this does require the latest version of bitbake to avoid adding the SDK dependencies (unless you call the -c populate_sdk, where they are added and used.)

--Mark

Quoted 98 lines

I am going to hold off on this patch set until this is resolved.

Thanks

Sau!

Quoted 90 lines

Signed-off-by Mark Hatle<[email protected]>

---
   meta/classes/image.bbclass             |    5 +++++
   meta/classes/populate_sdk_base.bbclass |    1 +
   meta/classes/populate_sdk_deb.bbclass  |    2 ++
   meta/classes/populate_sdk_ipk.bbclass  |    2 ++
   meta/classes/rootfs_deb.bbclass        |    2 ++
   meta/classes/rootfs_ipk.bbclass        |    2 ++
   6 files changed, 14 insertions(+), 0 deletions(-)

meta/classes/image.bbclass +5 -0

index 4f50376..7e41982 100644
@@ -3,6 +3,11 @@ inherit rootfs_${IMAGE_PKGTYPE}
   IMAGETEST ?= "dummy"
   inherit imagetest-${IMAGETEST}
 
+inherit populate_sdk_base
+
+TOOLCHAIN_TARGET_TASK += "${PACKAGE_INSTALL}"
+TOOLCHAIN_TARGET_TASK_ATTEMPTONLY += "${PACKAGE_INSTALL_ATTEMPTONLY} ${PACKAGE_GROUP_dev-pkgs} ${PACKAGE_GROUP_dbg-pkgs}"
+
   inherit gzipnative
 
   LICENSE = "MIT"

meta/classes/populate_sdk_base.bbclass +1 -0

index 6dc66fb..ed2dca0 100644
@@ -120,6 +120,7 @@ populate_sdk_log_check() {
   	done
   }
 
+do_populate_sdk[dirs] = "${TOPDIR}"
   do_populate_sdk[nostamp] = "1"
   do_populate_sdk[depends] = "${@' '.join([x + ':do_populate_sysroot' for x in d.getVar('SDK_DEPENDS', True).split()])}"
   do_populate_sdk[rdepends] = "${@' '.join([x + ':do_populate_sysroot' for x in d.getVar('SDK_RDEPENDS', True).split()])}"

meta/classes/populate_sdk_deb.bbclass +2 -0

index c3b3e0c..9e9e1e1 100644
@@ -6,6 +6,8 @@ DEB_SDK_ARCH = "${@[d.getVar('SDK_ARCH', True), "i386"]\
                   [d.getVar('SDK_ARCH', True) in \
                   ["x86", "i486", "i586", "i686", "pentium"]]}"
 
+do_populate_sdk[lockfiles] += "${WORKDIR}/deb.lock"
+
   populate_sdk_post_deb () {
 
   	local target_rootfs=$1

meta/classes/populate_sdk_ipk.bbclass +2 -0

index aa3efde..4321afb 100644
@@ -1,6 +1,8 @@
   do_populate_sdk[depends] += "opkg-native:do_populate_sysroot opkg-utils-native:do_populate_sysroot"
   do_populate_sdk[recrdeptask] += "do_package_write_ipk"
 
+do_populate_sdk[lockfiles] += "${WORKDIR}/ipk.lock"
+
   populate_sdk_ipk() {
 
   	rm -f ${IPKGCONF_TARGET}

meta/classes/rootfs_deb.bbclass +2 -0

index 6c9767f..4ea71da 100644
@@ -8,6 +8,8 @@ ROOTFS_PKGMANAGE_BOOTSTRAP  = "run-postinsts"
   do_rootfs[depends] += "dpkg-native:do_populate_sysroot apt-native:do_populate_sysroot"
   do_rootfs[recrdeptask] += "do_package_write_deb"
 
+do_rootfs[lockfiles] += "${WORKDIR}/deb.lock"
+
   DEB_POSTPROCESS_COMMANDS = "rootfs_install_all_locales; "
 
   opkglibdir = "${localstatedir}/lib/opkg"

meta/classes/rootfs_ipk.bbclass +2 -0

index 1580086..9732385 100644
@@ -12,6 +12,8 @@ ROOTFS_PKGMANAGE_BOOTSTRAP  = "run-postinsts"
   do_rootfs[depends] += "opkg-native:do_populate_sysroot opkg-utils-native:do_populate_sysroot"
   do_rootfs[recrdeptask] += "do_package_write_ipk"
 
+do_rootfs[lockfiles] += "${WORKDIR}/ipk.lock"
+
   IPKG_ARGS = "-f ${IPKGCONF_TARGET} -o ${IMAGE_ROOTFS} --force-overwrite"
 
   OPKG_PREPROCESS_COMMANDS = "package_update_index_ipk; package_generate_ipkg_conf"

Saul Wold

2012-07-02 20:17 UTC #9 lore raw

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

Quoted 37 lines · Mark Hatle

Quoted 36 lines · Saul Wold
Quoted 4 lines · Mark Hatle
When building an image recipe, you can now build a companion SDK by calling the populate_sdk task:
bitbake -c populate_sdk core-image-minimal
Quoted 8 lines
Note: there are still issues w/ the SDK not working completely with multilibs.
A lock is required between rootfs and populate_sdk activities to prevent configuration file clashes and similar package management problems in ipk
and deb based systems. (RPM already had a lock for a different reason.)
Mark this seems to have broken non-gplv3 builds. I get the following error now:
Quoted 19 lines
NOTE: Resolving any missing task queue dependencies
ERROR: Nothing RPROVIDES 'binutils-cross-canadian-i586' (but /intel/poky/distro/meta/recipes-core/tasks/task-cross-canadian.bb RDEPENDS on or otherwise requires it)
ERROR: binutils-cross-canadian-i586 was skipped: incompatible with license GPLv3
NOTE: Runtime target 'binutils-cross-canadian-i586' is unbuildable, removing...
Missing or unbuildable dependency chain was:
['binutils-cross-canadian-i586']
NOTE: Runtime target 'task-cross-canadian-i586' is unbuildable, removing...
Missing or unbuildable dependency chain was:
['task-cross-canadian-i586', 'binutils-cross-canadian-i586']
ERROR: Required build target 'core-image-minimal' has no buildable providers.
Missing or unbuildable dependency chain was: ['core-image-minimal', 'task-cross-canadian-i586', 'binutils-cross-canadian-i586']

Quoted 8 lines

Quoted 2 lines
Quoted 2 lines
Summary: There were 2 ERROR messages shown, returning a non-zero exit code.
As far as I know, this didn't work before either. If you are running:
bitbake core-image-minimal (or similar) it should work -exactly- as it did before, it's only if you add the -c .... that it will change.

I just did a git bisect and it works fine without your change and fails with your change. Not sure what you mean with the -c

Quoted 4 lines

I forgot to mention, this does require the latest version of bitbake to avoid adding the SDK dependencies (unless you call the -c populate_sdk, where they are added and used.)

Latest bitbake testing using poky-contrib/stage/master_under_test

Sau!

Quoted 116 lines

--Mark
Quoted 110 lines
I am going to hold off on this patch set until this is resolved.
Thanks
Sau!
Quoted 102 lines
Signed-off-by Mark Hatle<[email protected]>
---
meta/classes/image.bbclass | 5 +++++
meta/classes/populate_sdk_base.bbclass | 1 +
meta/classes/populate_sdk_deb.bbclass | 2 ++
meta/classes/populate_sdk_ipk.bbclass | 2 ++
meta/classes/rootfs_deb.bbclass | 2 ++
meta/classes/rootfs_ipk.bbclass | 2 ++
6 files changed, 14 insertions(+), 0 deletions(-)
meta/classes/image.bbclass +0 -0
index 4f50376..7e41982 100644
@@ -3,6 +3,11 @@ inherit rootfs_${IMAGE_PKGTYPE}
IMAGETEST ?= "dummy"
inherit imagetest-${IMAGETEST}
meta/classes/image.bbclass +4 -0
+inherit populate_sdk_base
+
+TOOLCHAIN_TARGET_TASK += "${PACKAGE_INSTALL}"
+TOOLCHAIN_TARGET_TASK_ATTEMPTONLY += "${PACKAGE_INSTALL_ATTEMPTONLY}
${PACKAGE_GROUP_dev-pkgs} ${PACKAGE_GROUP_dbg-pkgs}" +
inherit gzipnative
LICENSE = "MIT"
meta/classes/populate_sdk_base.bbclass +0 -0
index 6dc66fb..ed2dca0 100644
@@ -120,6 +120,7 @@ populate_sdk_log_check() {
done
}
+do_populate_sdk[dirs] = "${TOPDIR}" do_populate_sdk[nostamp] = "1"
do_populate_sdk[depends] = "${@' '.join([x + ':do_populate_sysroot' for x in d.getVar('SDK_DEPENDS', True).split()])}" do_populate_sdk[rdepends] = "${@' '.join([x + ':do_populate_sysroot' for x in d.getVar('SDK_RDEPENDS', True).split()])}"
meta/classes/populate_sdk_deb.bbclass +0 -0
index c3b3e0c..9e9e1e1 100644
@@ -6,6 +6,8 @@ DEB_SDK_ARCH = "${@[d.getVar('SDK_ARCH', True), "i386"]\
 [d.getVar('SDK_ARCH', True) in \
["x86", "i486", "i586", "i686", "pentium"]]}"
meta/classes/populate_sdk_deb.bbclass +2 -0
+do_populate_sdk[lockfiles] += "${WORKDIR}/deb.lock"
+
populate_sdk_post_deb () {
local target_rootfs=$1
meta/classes/populate_sdk_ipk.bbclass +0 -0
index aa3efde..4321afb 100644
@@ -1,6 +1,8 @@
do_populate_sdk[depends] += "opkg-native:do_populate_sysroot opkg-utils-native:do_populate_sysroot" do_populate_sdk[recrdeptask] += "do_package_write_ipk"
meta/classes/populate_sdk_ipk.bbclass +2 -0
+do_populate_sdk[lockfiles] += "${WORKDIR}/ipk.lock"
+
populate_sdk_ipk() {
rm -f ${IPKGCONF_TARGET}
meta/classes/rootfs_deb.bbclass +0 -0
index 6c9767f..4ea71da 100644
@@ -8,6 +8,8 @@ ROOTFS_PKGMANAGE_BOOTSTRAP = "run-postinsts"
do_rootfs[depends] += "dpkg-native:do_populate_sysroot apt-native:do_populate_sysroot" do_rootfs[recrdeptask] += "do_package_write_deb"
meta/classes/rootfs_deb.bbclass +2 -0
+do_rootfs[lockfiles] += "${WORKDIR}/deb.lock"
+
DEB_POSTPROCESS_COMMANDS = "rootfs_install_all_locales; "
opkglibdir = "${localstatedir}/lib/opkg"
meta/classes/rootfs_ipk.bbclass +0 -0
index 1580086..9732385 100644
@@ -12,6 +12,8 @@ ROOTFS_PKGMANAGE_BOOTSTRAP = "run-postinsts"
do_rootfs[depends] += "opkg-native:do_populate_sysroot opkg-utils-native:do_populate_sysroot" do_rootfs[recrdeptask] += "do_package_write_ipk"
meta/classes/rootfs_ipk.bbclass +2 -0
+do_rootfs[lockfiles] += "${WORKDIR}/ipk.lock"
+
IPKG_ARGS = "-f ${IPKGCONF_TARGET} -o ${IMAGE_ROOTFS} --force-overwrite"
OPKG_PREPROCESS_COMMANDS = "package_update_index_ipk; package_generate_ipkg_conf"

Phil Blundell

2012-07-02 20:25 UTC #10 lore raw

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

In reply to Mark Hatle

meta/classes/image.bbclass inherit rootfs_${IMAGE_PKGTYPE} · line 6

Quoted 9 lines · Mark Hatle

meta/classes/image.bbclass +1 -0

index 4f50376..7e41982 100644
@@ -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?

Mark Hatle

author

2012-07-02 20:44 UTC #11 lore raw

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

Quoted 9 lines · Phil Blundell

Quoted 8 lines · Mark Hatle

meta/classes/image.bbclass +0 -0

index 4f50376..7e41982 100644
@@ -3,6 +3,11 @@ inherit rootfs_${IMAGE_PKGTYPE}
  IMAGETEST ?= "dummy"
  inherit imagetest-${IMAGETEST}

Quoted 4 lines

meta/classes/image.bbclass inherit rootfs_${IMAGE_PKGTYPE} · line 6
Quoted 1 line
meta/classes/image.bbclass +1 -0
+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.

--Mark

Quoted 9 lines

p.
_______________________________________________
Openembedded-core mailing list
[email protected]
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core

Phil Blundell

2012-07-02 21:17 UTC #12 lore raw

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

Quoted 15 lines · Mark Hatle

Quoted 9 lines · Phil Blundell
Quoted 8 lines · Mark Hatle
meta/classes/image.bbclass +0 -0
index 4f50376..7e41982 100644
@@ -3,6 +3,11 @@ inherit rootfs_${IMAGE_PKGTYPE}
  IMAGETEST ?= "dummy"
  inherit imagetest-${IMAGETEST}
 
Quoted 4 lines
meta/classes/image.bbclass inherit rootfs_${IMAGE_PKGTYPE} · line 6
Quoted 1 line
meta/classes/image.bbclass +1 -0
+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?

Quoted 5 lines

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.

Mark Hatle

author

2012-07-02 21:48 UTC #13 lore raw

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

Quoted 18 lines · Phil Blundell

Quoted 17 lines · Mark Hatle
Quoted 9 lines · Phil Blundell
Quoted 8 lines · Mark Hatle
meta/classes/image.bbclass +0 -0
index 4f50376..7e41982 100644
@@ -3,6 +3,11 @@ inherit rootfs_${IMAGE_PKGTYPE}
   IMAGETEST ?= "dummy"
   inherit imagetest-${IMAGETEST}
 
Quoted 4 lines
meta/classes/image.bbclass inherit rootfs_${IMAGE_PKGTYPE} · line 6
Quoted 1 line
meta/classes/image.bbclass +1 -0
+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.

Quoted 8 lines

Quoted 3 lines
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.

Quoted 4 lines

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.

Quoted 5 lines

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

Quoted 9 lines

p.
_______________________________________________
Openembedded-core mailing list
[email protected]
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core

Saul Wold

2012-07-03 23:58 UTC #14 lore raw

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

In reply to Mark Hatle

Quoted 6 lines · Mark Hatle

When building an image recipe, you can now build a companion SDK by calling the populate_sdk task:
bitbake -c populate_sdk core-image-minimal
Note: there are still issues w/ the SDK not working completely with multilibs.

So this does break the default multi-lib build also, I thought it was a transient problem at first, but it's very reproducible.

Add these to your local.conf
require conf/multilib.conf
MULTILIBS = "multilib:lib32"
DEFAULTTUNE_virtclass-multilib-lib32 = "x86"

bitbake lib32-core-image-minimal

Then wait and:

Quoted 12 lines

ERROR: Logfile of failure stored in: /srv/ssd/sgw_ab/yocto-autobuilder/yocto-slave/nightly-multilib/build/build/tmp/work/qemux86_64-poky-linux/lib32-core-image-minimal-1.0-r0/temp/log.do_rootfs.39788 Log data follows:

| DEBUG: Executing shell function do_rootfs
| Generating solve db for /srv/ssd/sgw_ab/yocto-autobuilder/yocto-slave/nightly-multilib/build/build/tmp/deploy/rpm/qemux86_64...
| Generating solve db for /srv/ssd/sgw_ab/yocto-autobuilder/yocto-slave/nightly-multilib/build/build/tmp/deploy/rpm/x86_64...
| Generating solve db for /srv/ssd/sgw_ab/yocto-autobuilder/yocto-slave/nightly-multilib/build/build/tmp/deploy/rpm/all...
| Generating solve db for /srv/ssd/sgw_ab/yocto-autobuilder/yocto-slave/nightly-multilib/build/build/tmp/deploy/rpm/qemux86_64...
| Generating solve db for /srv/ssd/sgw_ab/yocto-autobuilder/yocto-slave/nightly-multilib/build/build/tmp/deploy/rpm/all...
| Generating solve db for /srv/ssd/sgw_ab/yocto-autobuilder/yocto-slave/nightly-multilib/build/build/tmp/deploy/rpm/all...
| Processing lib32-task-core-boot...
| Unable to find package lib32-task-core-boot (task-core-boot)!
| ERROR: Function failed: do_rootfs (see /srv/ssd/sgw_ab/yocto-autobuilder/yocto-slave/nightly-multilib/build/build/tmp/work/qemux86_64-poky-linux/lib32-core-image-minimal-1.0-r0/temp/log.do_rootfs.39788 for further information)

Quoted 1 line

NOTE: package lib32-core-image-minimal-1.0-r0: task do_rootfs: Failed

The rpm seem to exist, but not getting mapped properly??

ls tmp/deploy/rpm/*/*task-core* tmp/deploy/rpm/lib32_qemux86_64/task-core-boot-1.0-r9.lib32_qemux86_64.rpm

Quoted 7 lines

rpm -q -p tmp/deploy/rpm/lib32_qemux86_64/task-core-boot-1.0-r9.lib32_qemux86_64.rpm --info
warning: tmp/deploy/rpm/lib32_qemux86_64/task-core-boot-1.0-r9.lib32_qemux86_64.rpm: Header V4 DSA/SHA1 Signature, key ID f72af359: NOKEY
Name : task-core-boot Relocations: (not relocatable)
Version : 1.0 Vendor: (none)
Release : r9 Build Date: Tue 03 Jul 2012 04:03:16 PM PDT
Install Date: (not installed) Build Host: yocto-hm1.jf.intel.com
Group : base Source RPM: task-core-boot-1.0-r9.src.rpm

Quoted 8 lines

Size : 0 License: MIT
Signature : DSA/SHA1, Tue 03 Jul 2012 04:03:16 PM PDT, Key ID 6a15ede1f72af359
Packager : Poky <[email protected]>
URL : unknown
Summary : lib32-task-core-boot version 1.0-r9
Description :
Task for OpenedHand Poky - minimal bootable image
Distribution: (none)

Other RPM queries yielded nothing or (contains no files)
-c, --dump, --list, --provides

I hope you are able to look into this a little deeper on Thursday

Thanks
Sau!

Quoted 95 lines

Signed-off-by Mark Hatle<[email protected]>

---
  meta/classes/image.bbclass             |    5 +++++
  meta/classes/populate_sdk_base.bbclass |    1 +
  meta/classes/populate_sdk_deb.bbclass  |    2 ++
  meta/classes/populate_sdk_ipk.bbclass  |    2 ++
  meta/classes/rootfs_deb.bbclass        |    2 ++
  meta/classes/rootfs_ipk.bbclass        |    2 ++
  6 files changed, 14 insertions(+), 0 deletions(-)

meta/classes/image.bbclass +5 -0

index 4f50376..7e41982 100644
@@ -3,6 +3,11 @@ inherit rootfs_${IMAGE_PKGTYPE}
  IMAGETEST ?= "dummy"
  inherit imagetest-${IMAGETEST}
 
+inherit populate_sdk_base
+
+TOOLCHAIN_TARGET_TASK += "${PACKAGE_INSTALL}"
+TOOLCHAIN_TARGET_TASK_ATTEMPTONLY += "${PACKAGE_INSTALL_ATTEMPTONLY} ${PACKAGE_GROUP_dev-pkgs} ${PACKAGE_GROUP_dbg-pkgs}"
+
  inherit gzipnative
 
  LICENSE = "MIT"

meta/classes/populate_sdk_base.bbclass +1 -0

index 6dc66fb..ed2dca0 100644
@@ -120,6 +120,7 @@ populate_sdk_log_check() {
  	done
  }
 
+do_populate_sdk[dirs] = "${TOPDIR}"
  do_populate_sdk[nostamp] = "1"
  do_populate_sdk[depends] = "${@' '.join([x + ':do_populate_sysroot' for x in d.getVar('SDK_DEPENDS', True).split()])}"
  do_populate_sdk[rdepends] = "${@' '.join([x + ':do_populate_sysroot' for x in d.getVar('SDK_RDEPENDS', True).split()])}"

meta/classes/populate_sdk_deb.bbclass +2 -0

index c3b3e0c..9e9e1e1 100644
@@ -6,6 +6,8 @@ DEB_SDK_ARCH = "${@[d.getVar('SDK_ARCH', True), "i386"]\
                  [d.getVar('SDK_ARCH', True) in \
                  ["x86", "i486", "i586", "i686", "pentium"]]}"
 
+do_populate_sdk[lockfiles] += "${WORKDIR}/deb.lock"
+
  populate_sdk_post_deb () {
 
  	local target_rootfs=$1

meta/classes/populate_sdk_ipk.bbclass +2 -0

index aa3efde..4321afb 100644
@@ -1,6 +1,8 @@
  do_populate_sdk[depends] += "opkg-native:do_populate_sysroot opkg-utils-native:do_populate_sysroot"
  do_populate_sdk[recrdeptask] += "do_package_write_ipk"
 
+do_populate_sdk[lockfiles] += "${WORKDIR}/ipk.lock"
+
  populate_sdk_ipk() {
 
  	rm -f ${IPKGCONF_TARGET}

meta/classes/rootfs_deb.bbclass +2 -0

index 6c9767f..4ea71da 100644
@@ -8,6 +8,8 @@ ROOTFS_PKGMANAGE_BOOTSTRAP  = "run-postinsts"
  do_rootfs[depends] += "dpkg-native:do_populate_sysroot apt-native:do_populate_sysroot"
  do_rootfs[recrdeptask] += "do_package_write_deb"
 
+do_rootfs[lockfiles] += "${WORKDIR}/deb.lock"
+
  DEB_POSTPROCESS_COMMANDS = "rootfs_install_all_locales; "
 
  opkglibdir = "${localstatedir}/lib/opkg"

meta/classes/rootfs_ipk.bbclass +2 -0

index 1580086..9732385 100644
@@ -12,6 +12,8 @@ ROOTFS_PKGMANAGE_BOOTSTRAP  = "run-postinsts"
  do_rootfs[depends] += "opkg-native:do_populate_sysroot opkg-utils-native:do_populate_sysroot"
  do_rootfs[recrdeptask] += "do_package_write_ipk"
 
+do_rootfs[lockfiles] += "${WORKDIR}/ipk.lock"
+
  IPKG_ARGS = "-f ${IPKGCONF_TARGET} -o ${IMAGE_ROOTFS} --force-overwrite"
 
  OPKG_PREPROCESS_COMMANDS = "package_update_index_ipk; package_generate_ipkg_conf"

McClintock Matthew-B29882

2012-07-02 16:31 UTC #15 lore raw

In reply to Mark Hatle

Mark,

By 'match the image' you mean the libraries in the toolchain tarball will contain matching versions that are on the root file system?

-M

Quoted 54 lines · Mark Hatle

Only difference is patch 1/6, I accidently sent and older broken version of the patch. This is the correct version.
---
After this series of patches, it is possible to generate an SDK that matches the image. The SDK and all related code is only activated if an image recipe is built using the "populate_sdk" task, such as:
bitbake core-image-sato -c populate_sdk
Existing SDK images, such as meta-toolchain or meta-toolchain-gmae continue to work without modifications.
The following changes since commit 54429dfcca0e35a3aeaa78e509240b87d6a8f4ac:
mklibs-native: Upgrade to 0.1.34 (2012-06-29 13:21:19 +0100)
are available in the git repository at:
git://git.pokylinux.org/poky-contrib mhatle/sdk
http://git.pokylinux.org/cgit.cgi/poky-contrib/log/?h=mhatle/sdk
Mark Hatle (6):
Fix manual log file paths
populate_sdk.bbclass: Split into two parts
populate_sdk: Allow for attempt only packages in the SDK populate_sdk_base.bbclass: Change to using task specific depends
populate_sdk: enable basic multilib support image.bbclass: Add support to build the SDK in parallel with the image
meta/classes/image.bbclass | 7 ++-
 meta/classes/package_deb.bbclass       |    4 +-
 meta/classes/package_ipk.bbclass       |    2 +-
 meta/classes/package_rpm.bbclass       |   10 +-
 meta/classes/populate_sdk.bbclass      |   91 +---------------------
 meta/classes/populate_sdk_base.bbclass |  128 ++++++++++++++++++++++++++++++++
 meta/classes/populate_sdk_deb.bbclass  |    6 +-
 meta/classes/populate_sdk_ipk.bbclass  |    5 +-
 meta/classes/populate_sdk_rpm.bbclass  |    4 +-
 meta/classes/rootfs_deb.bbclass        |    2 +
 meta/classes/rootfs_ipk.bbclass        |    2 +
 meta/classes/toolchain-scripts.bbclass |   16 +++--
 12 files changed, 170 insertions(+), 107 deletions(-)
create mode 100644 meta/classes/populate_sdk_base.bbclass
--
1.7.3.4
_______________________________________________
Openembedded-core mailing list
[email protected]
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core

Mark Hatle

author

2012-07-02 16:38 UTC #16 lore raw

Quoted 4 lines · On 7/2/12 10:20 AM, McClintock Matthew-B29882 wrote:

Mark,
By 'match the image' you mean the libraries in the toolchain tarball will contain matching versions that are on the root file system?

If you create an image that only has busybox, and glibc.. a matching SDK would only include busybox and glibc (development) components as well.

You won't get libstdc++, glib, libX11, or anything else that is not part of the image..

For my customers they create a base platform image. This image defines all of the (external to them) software that will be running on their devices. They then use that image to create an SDK to pass to their internal (and external) application developers. So it's critical the SDK match the image they generated. (And they, and I, don't see why in this case making an external SDK recipe makes sense.. the SDK should simply match the image... Note, there is definitely a case where you want to build an application SDK that does not match the image... Usually this is done when you only want app developers to use a limited set of APIs for their apps.)

So yes, the SDK will match the libraires selected for an image, and provide the -dev and -dbg versions of the components. (-staticdev is not included...)

--Mark

Quoted 63 lines

-M
Quoted 46 lines · Mark Hatle
Only difference is patch 1/6, I accidently sent and older broken version of the patch. This is the correct version.
---
After this series of patches, it is possible to generate an SDK that matches the image. The SDK and all related code is only activated if an image recipe is built using the "populate_sdk" task, such as:
bitbake core-image-sato -c populate_sdk
Existing SDK images, such as meta-toolchain or meta-toolchain-gmae continue to work without modifications.
The following changes since commit 54429dfcca0e35a3aeaa78e509240b87d6a8f4ac:
   mklibs-native: Upgrade to 0.1.34 (2012-06-29 13:21:19 +0100)
are available in the git repository at:
git://git.pokylinux.org/poky-contrib mhatle/sdk
http://git.pokylinux.org/cgit.cgi/poky-contrib/log/?h=mhatle/sdk
Mark Hatle (6):
Fix manual log file paths
populate_sdk.bbclass: Split into two parts
populate_sdk: Allow for attempt only packages in the SDK populate_sdk_base.bbclass: Change to using task specific depends
populate_sdk: enable basic multilib support image.bbclass: Add support to build the SDK in parallel with the
image
  meta/classes/image.bbclass             |    7 ++-
  meta/classes/package_deb.bbclass       |    4 +-
  meta/classes/package_ipk.bbclass       |    2 +-
  meta/classes/package_rpm.bbclass       |   10 +-
  meta/classes/populate_sdk.bbclass      |   91 +---------------------
  meta/classes/populate_sdk_base.bbclass |  128 ++++++++++++++++++++++++++++++++
  meta/classes/populate_sdk_deb.bbclass  |    6 +-
  meta/classes/populate_sdk_ipk.bbclass  |    5 +-
  meta/classes/populate_sdk_rpm.bbclass  |    4 +-
  meta/classes/rootfs_deb.bbclass        |    2 +
  meta/classes/rootfs_ipk.bbclass        |    2 +
  meta/classes/toolchain-scripts.bbclass |   16 +++--
  12 files changed, 170 insertions(+), 107 deletions(-)
create mode 100644 meta/classes/populate_sdk_base.bbclass
Quoted 8 lines
--
1.7.3.4
_______________________________________________
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