[RFC PATCH 0/6] (e)SDK workflow directly in a Yocto build

[RFC PATCH 0/6] (e)SDK workflow directly in a Yocto build

[Alexander Kanavin]

There's been a recent discussion about how we can make the Yocto SDK
experience better [1]. One of the ideas was to eliminate the SDK
as a separate artefact altogether and simply provide everything
that the SDK and eSDKs do directly in a yocto build. This does not
mean that people have to 'learn Yocto', but rather that the integrators
should provide a well-functioning sstate cache infrastructure (same as
with minimal eSDK, really), and a few wrapper scripts for setting up the build
and the SDK environment that run layer setup and bitbake behind the scenes.

[1] https://lists.openembedded.org/g/openembedded-architecture/topic/thoughts_on_the_esdk/90990557

So without further ado, here's how you get a 'SDK' with this set of patches:

1. Set up all the needed layers and a yocto build directory.

2. Run:
$ bitbake meta-ide-support
$ bitbake -c populate_sysroot gtk+3
(or any other target or native item that the application developer would need)
$ bitbake populate-sysroots

3. Set up the SDK environment:
. tmp/deploy/images/qemux86-64/environment-setup-core2-64-poky-linux
(adjust accordingly)

Et voila! The Unix environment is now set up to use the cross-toolchain from
Yocto, exactly as in the SDK. And devtool/bitbake are available to extend it,
exactly as in the eSDK.

Theare are numerous benefits here: no need to produce, test, distribute and maintain
separate SDK artifacts. No two separate environments for the yocto build and the SDK.
Less code paths where things can go wrong. Less awkward, gigantic tarballs. Less
SDK update headaches: 'updating the SDK' simply means updating the yocto layers with
git fetch or layer management tooling. Built-in SDK extensibility: just run bitbake
again to add more things to the sysroot, or add layers if even more things are required.

How is this tested?

Exactly same as the regular SDK:
$ bitbake -c testsdk meta-ide-support

This runs the same toolchain tests from meta/lib/oeqa/sdk/cases as the regular
sdk testing does.

One known issue is that the libepoxy test is failing: libepoxy is built with meson,
and meson requires the build configuration to be provided with native/cross files and not
in the unix environment. This is addressed in the 'classic SDK' through a wrapper for the binary,
and something similar will be added to meta-ide-support as well.


Alexander Kanavin (6):
  toolchain-scripts.bbclass: adjust toolchain_create_tree_env_script to
    better replicate (e)SDK
  meta-ide-support: adjust to provide (e)SDK experience directly in a
    yocto build
  oeqa/sdk: add a test class for running SDK tests directly in a Yocto
    build
  selftest/meta_ide: add a test for running SDK tests
  oeqa/sdk: allow epoxy/galculator tests to run in esdk and direct yocto
    builds
  oeqa/sdk: drop the nativesdk-python 2.x test

 meta/classes/toolchain-scripts.bbclass     | 23 +++++++-----
 meta/lib/oeqa/sdk/cases/buildepoxy.py      |  3 +-
 meta/lib/oeqa/sdk/cases/buildgalculator.py |  3 +-
 meta/lib/oeqa/sdk/cases/python.py          | 11 ------
 meta/lib/oeqa/sdk/testmetaidesupport.py    | 43 ++++++++++++++++++++++
 meta/lib/oeqa/selftest/cases/meta_ide.py   | 14 +++++--
 meta/recipes-core/meta/meta-ide-support.bb | 26 +++++++++++--
 7 files changed, 94 insertions(+), 29 deletions(-)
 create mode 100644 meta/lib/oeqa/sdk/testmetaidesupport.py

-- 
2.30.2

[RFC PATCH 1/6] toolchain-scripts.bbclass: adjust toolchain_create_tree_env_script to better replicate (e)SDK

[Alexander Kanavin]

Specifically:
1. Place the environment setup file into $B and not into $TMPDIR,
so that the recipe using the class can itself better decide what to do with the file.

2. Use global, unified sysroots (provided through build-sysroots recipe)
and not recipe-specific ones, as this allows flexible on-the-fly management of what
libraries are available to build applications, without having to modify any
recipes, similar to eSDK 'extensible' part.

3. Add a few missing settings that have been added to SDK environment files.

Signed-off-by: Alexander Kanavin <alex@linutronix.de>
---
 meta/classes/toolchain-scripts.bbclass | 23 ++++++++++++++---------
 1 file changed, 14 insertions(+), 9 deletions(-)

diff --git a/meta/classes/toolchain-scripts.bbclass b/meta/classes/toolchain-scripts.bbclass
index 1d7c703748..e46d27ebc7 100644
--- a/meta/classes/toolchain-scripts.bbclass
+++ b/meta/classes/toolchain-scripts.bbclass
@@ -63,22 +63,27 @@ toolchain_create_sdk_env_script () {
 	toolchain_shared_env_script
 }
 
-# This function creates an environment-setup-script in the TMPDIR which enables
+# This function creates an environment-setup-script in B which enables
 # a OE-core IDE to integrate with the build tree
 # Caller must ensure CONFIG_SITE is setup
 toolchain_create_tree_env_script () {
-	script=${TMPDIR}/environment-setup-${REAL_MULTIMACH_TARGET_SYS}
+	script=${B}/environment-setup-${REAL_MULTIMACH_TARGET_SYS}
 	rm -f $script
 	touch $script
+	echo 'standalone_sysroot_target="${STAGING_DIR}/${MACHINE}"' >> $script
+	echo 'standalone_sysroot_native="${STAGING_DIR}/${BUILD_ARCH}"' >> $script
 	echo 'orig=`pwd`; cd ${COREBASE}; . ./oe-init-build-env ${TOPDIR}; cd $orig' >> $script
-	echo 'export PATH=${STAGING_DIR_NATIVE}/usr/bin:${STAGING_BINDIR_TOOLCHAIN}:$PATH' >> $script
-	echo 'export PKG_CONFIG_SYSROOT_DIR=${PKG_CONFIG_SYSROOT_DIR}' >> $script
-	echo 'export PKG_CONFIG_PATH=${PKG_CONFIG_PATH}' >> $script
+	echo 'export PATH=$standalone_sysroot_native/${bindir_native}:$standalone_sysroot_native/${bindir_native}/${TARGET_SYS}:$PATH' >> $script
+	echo 'export PKG_CONFIG_SYSROOT_DIR=$standalone_sysroot_target' >> $script
+	echo 'export PKG_CONFIG_PATH=$standalone_sysroot_target'"$libdir"'/pkgconfig:$standalone_sysroot_target'"$prefix"'/share/pkgconfig' >> $script
 	echo 'export CONFIG_SITE="${CONFIG_SITE}"' >> $script
-	echo 'export SDKTARGETSYSROOT=${STAGING_DIR_TARGET}' >> $script
-	echo 'export OECORE_NATIVE_SYSROOT="${STAGING_DIR_NATIVE}"' >> $script
-	echo 'export OECORE_TARGET_SYSROOT="${STAGING_DIR_TARGET}"' >> $script
-	echo 'export OECORE_ACLOCAL_OPTS="-I ${STAGING_DIR_NATIVE}/usr/share/aclocal"' >> $script
+	echo 'export SDKTARGETSYSROOT=$standalone_sysroot_target' >> $script
+	echo 'export OECORE_NATIVE_SYSROOT=$standalone_sysroot_native' >> $script
+	echo 'export OECORE_TARGET_SYSROOT=$standalone_sysroot_target' >> $script
+	echo 'export OECORE_ACLOCAL_OPTS="-I $standalone_sysroot_native/usr/share/aclocal"' >> $script
+	echo 'export OECORE_BASELIB="${baselib}"' >> $script
+	echo 'export OECORE_TARGET_ARCH="${TARGET_ARCH}"' >>$script
+	echo 'export OECORE_TARGET_OS="${TARGET_OS}"' >>$script
 
 	toolchain_shared_env_script
 }
-- 
2.30.2

[RFC PATCH 2/6] meta-ide-support: adjust to provide (e)SDK experience directly in a yocto build

[Alexander Kanavin]

Specifically:
1. Add a few more toolchain items to DEPENDS so they're available in the recipe sysroot.
2. Use deploy mechanism to place the SDK environment setup file and testdata for testing it
into the image deploy directory.
3. Add ability to run SDK tests via the testsdk class and task. This also requires providing
a testdata json file.
4. Ensure sysroot population always runs, as those items are mean to be picked up
by 'bitbake build-sysroots' into the unified sysroot.

Signed-off-by: Alexander Kanavin <alex@linutronix.de>
---
 meta/recipes-core/meta/meta-ide-support.bb | 26 +++++++++++++++++++---
 1 file changed, 23 insertions(+), 3 deletions(-)

diff --git a/meta/recipes-core/meta/meta-ide-support.bb b/meta/recipes-core/meta/meta-ide-support.bb
index 39317d50e0..3d480c71d4 100644
--- a/meta/recipes-core/meta/meta-ide-support.bb
+++ b/meta/recipes-core/meta/meta-ide-support.bb
@@ -2,11 +2,13 @@ SUMMARY = "Integrated Development Environment support"
 DESCRIPTION = "Meta package for ensuring the build directory contains all appropriate toolchain packages for using an IDE"
 LICENSE = "MIT"
 
-DEPENDS = "virtual/libc gdb-cross-${TARGET_ARCH} qemu-native qemu-helper-native unfs3-native cmake-native"
+DEPENDS = "virtual/libc gdb-cross-${TARGET_ARCH} qemu-native qemu-helper-native unfs3-native cmake-native autoconf-native automake-native meson-native intltool-native pkgconfig-native"
 PR = "r3"
 RM_WORK_EXCLUDE += "${PN}"
 
-inherit toolchain-scripts nopackages
+inherit toolchain-scripts nopackages deploy testsdk
+
+TESTSDK_CLASS_NAME = "oeqa.sdk.testmetaidesupport.TestSDK"
 
 do_populate_ide_support () {
   toolchain_create_tree_env_script
@@ -18,4 +20,22 @@ python () {
     d.appendVarFlag("do_populate_ide_support", "file-checksums", " " + " ".join(searched))
 }
 
-addtask populate_ide_support before do_build after do_install
+addtask populate_ide_support before do_deploy after do_install
+
+python do_write_test_data() {
+    from oe.data import export2json
+
+    out_dir = d.getVar('B')
+    testdata_name = os.path.join(out_dir, "%s.testdata.json" % d.getVar('PN'))
+
+    export2json(d, testdata_name)
+}
+addtask write_test_data before do_deploy after do_install
+
+do_deploy () {
+        install ${B}/* ${DEPLOYDIR}
+}
+
+addtask deploy before do_build
+
+do_prepare_recipe_sysroot[nostamp] = "1"
-- 
2.30.2

Re: [OE-core] [RFC PATCH 2/6] meta-ide-support: adjust to provide (e)SDK experience directly in a yocto build

[Luca Ceresoli]

Hi Alex,

On Wed, 22 Jun 2022 12:33:08 +0200
"Alexander Kanavin" <alex.kanavin@gmail.com> wrote:

> Specifically:
> 1. Add a few more toolchain items to DEPENDS so they're available in the recipe sysroot.
> 2. Use deploy mechanism to place the SDK environment setup file and testdata for testing it
> into the image deploy directory.
> 3. Add ability to run SDK tests via the testsdk class and task. This also requires providing
> a testdata json file.
> 4. Ensure sysroot population always runs, as those items are mean to be picked up
> by 'bitbake build-sysroots' into the unified sysroot.
> 
> Signed-off-by: Alexander Kanavin <alex@linutronix.de>


This series is failing on the ABs:

AssertionError: Adding layer meta-mingw changed signatures.
9 signatures changed, initial differences (first hash before, second after):
   meta-ide-support:do_prepare_recipe_sysroot: 8a46421fcb080b73cb27047df1d44a256ccb8115ff5646e8a312a9437d8544dd -> 13c339e339f0e7bd9cd13fcdb28135f37de785dd801e64588e240eced8c1e8c4
      bitbake-diffsigs --task meta-ide-support do_prepare_recipe_sysroot --signature 8a46421fcb080b73cb27047df1d44a256ccb8115ff5646e8a312a9437d8544dd 13c339e339f0e7bd9cd13fcdb28135f37de785dd801e64588e240eced8c1e8c4
      NOTE: Starting bitbake server...
      Taint (by forced/invalidated task) changed from nostamp(uuid4):33106dd5-141b-4115-95b2-69cf0d5d6e2c to nostamp(uuid4):b8a53034-116c-44e6-87a4-744d6c021eb1

Logs:

https://autobuilder.yoctoproject.org/typhoon/#/builders/39/builds/5417/steps/15/logs/stdio
https://autobuilder.yoctoproject.org/typhoon/#/builders/39/builds/5417/steps/17/logs/stdio

-- 
Luca Ceresoli, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com

Re: [OE-core] [RFC PATCH 2/6] meta-ide-support: adjust to provide (e)SDK experience directly in a yocto build

[Alexander Kanavin]

Thanks Luca, this was not meant for merging (RFC), but it helps to see
the issues upfront.

Alex

On Thu, 23 Jun 2022 at 12:03, Luca Ceresoli <luca.ceresoli@bootlin.com> wrote:
>
> Hi Alex,
>
> On Wed, 22 Jun 2022 12:33:08 +0200
> "Alexander Kanavin" <alex.kanavin@gmail.com> wrote:
>
> > Specifically:
> > 1. Add a few more toolchain items to DEPENDS so they're available in the recipe sysroot.
> > 2. Use deploy mechanism to place the SDK environment setup file and testdata for testing it
> > into the image deploy directory.
> > 3. Add ability to run SDK tests via the testsdk class and task. This also requires providing
> > a testdata json file.
> > 4. Ensure sysroot population always runs, as those items are mean to be picked up
> > by 'bitbake build-sysroots' into the unified sysroot.
> >
> > Signed-off-by: Alexander Kanavin <alex@linutronix.de>
>
>
> This series is failing on the ABs:
>
> AssertionError: Adding layer meta-mingw changed signatures.
> 9 signatures changed, initial differences (first hash before, second after):
>    meta-ide-support:do_prepare_recipe_sysroot: 8a46421fcb080b73cb27047df1d44a256ccb8115ff5646e8a312a9437d8544dd -> 13c339e339f0e7bd9cd13fcdb28135f37de785dd801e64588e240eced8c1e8c4
>       bitbake-diffsigs --task meta-ide-support do_prepare_recipe_sysroot --signature 8a46421fcb080b73cb27047df1d44a256ccb8115ff5646e8a312a9437d8544dd 13c339e339f0e7bd9cd13fcdb28135f37de785dd801e64588e240eced8c1e8c4
>       NOTE: Starting bitbake server...
>       Taint (by forced/invalidated task) changed from nostamp(uuid4):33106dd5-141b-4115-95b2-69cf0d5d6e2c to nostamp(uuid4):b8a53034-116c-44e6-87a4-744d6c021eb1
>
> Logs:
>
> https://autobuilder.yoctoproject.org/typhoon/#/builders/39/builds/5417/steps/15/logs/stdio
> https://autobuilder.yoctoproject.org/typhoon/#/builders/39/builds/5417/steps/17/logs/stdio
>
> --
> Luca Ceresoli, Bootlin
> Embedded Linux and Kernel engineering
> https://bootlin.com

Re: [OE-core] [RFC PATCH 2/6] meta-ide-support: adjust to provide (e)SDK experience directly in a yocto build

[Luca Ceresoli]

Hi Alex,

On Thu, 23 Jun 2022 16:52:55 +0200
Alexander Kanavin <alex.kanavin@gmail.com> wrote:

> Thanks Luca, this was not meant for merging (RFC), but it helps to see
> the issues upfront.

Sure, however Richard asked me to test this on the autobuilders.

Cheers.
-- 
Luca Ceresoli, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com

[RFC PATCH 3/6] oeqa/sdk: add a test class for running SDK tests directly in a Yocto build

[Alexander Kanavin]

This is a simpler version of the same class in testsdk.py, as it does not
need to unpack and set up the SDK, and can proceed to the tests straight away.

Signed-off-by: Alexander Kanavin <alex@linutronix.de>
---
 meta/lib/oeqa/sdk/testmetaidesupport.py | 43 +++++++++++++++++++++++++
 1 file changed, 43 insertions(+)
 create mode 100644 meta/lib/oeqa/sdk/testmetaidesupport.py

diff --git a/meta/lib/oeqa/sdk/testmetaidesupport.py b/meta/lib/oeqa/sdk/testmetaidesupport.py
new file mode 100644
index 0000000000..2ff76fd8e0
--- /dev/null
+++ b/meta/lib/oeqa/sdk/testmetaidesupport.py
@@ -0,0 +1,43 @@
+#
+# SPDX-License-Identifier: MIT
+#
+
+class TestSDK(object):
+    def run(self, d):
+        import json
+        import logging
+        from oeqa.sdk.context import OESDKTestContext, OESDKTestContextExecutor
+        from oeqa.utils import make_logger_bitbake_compatible
+
+        pn = d.getVar("PN")
+
+        logger = make_logger_bitbake_compatible(logging.getLogger("BitBake"))
+
+        sdk_dir = d.expand("${WORKDIR}/testsdk/")
+        bb.utils.remove(sdk_dir, True)
+        bb.utils.mkdirhier(sdk_dir)
+
+        sdk_envs = OESDKTestContextExecutor._get_sdk_environs(d.getVar("DEPLOY_DIR_IMAGE"))
+        tdname = d.expand("${DEPLOY_DIR_IMAGE}/${PN}.testdata.json")
+        test_data = json.load(open(tdname, "r"))
+
+        host_pkg_manifest = {"cmake-native":"", "gcc-cross":"", "gettext-native":"", "meson-native":"", "perl-native":"", "python3-core-native":"", }
+        target_pkg_manifest = {"gtk+3":""}
+
+        for s in sdk_envs:
+            bb.plain("meta-ide-support based SDK testing environment: %s" % s)
+
+            sdk_env = sdk_envs[s]
+
+            tc = OESDKTestContext(td=test_data, logger=logger, sdk_dir=sdk_dir,
+                sdk_env=sdk_env, target_pkg_manifest=target_pkg_manifest,
+                host_pkg_manifest=host_pkg_manifest)
+
+            tc.loadTests(OESDKTestContextExecutor.default_cases)
+
+            results = tc.runTests()
+            if results:
+                results.logSummary(pn)
+
+            if (not results) or (not results.wasSuccessful()):
+                bb.fatal('%s - FAILED' % (pn,), forcelog=True)
-- 
2.30.2

[RFC PATCH 4/6] selftest/meta_ide: add a test for running SDK tests

[Alexander Kanavin]

This also shows how the SDK workflow inside a Yocto build works:

bitbake meta-ide-support
bitbake -c populate_sysroot gtk+3 (or any other needed target/native item for development)
bitbake build-sysroots
. tmp/deploy/images/qemux86-64/environment-setup-core2-64-poky-linux

And voila: just the same environment as the (e)SDK.

Adjust the location of environment script to be in deploy dir, not in tmp dir.

Signed-off-by: Alexander Kanavin <alex@linutronix.de>
---
 meta/lib/oeqa/selftest/cases/meta_ide.py | 14 ++++++++++----
 1 file changed, 10 insertions(+), 4 deletions(-)

diff --git a/meta/lib/oeqa/selftest/cases/meta_ide.py b/meta/lib/oeqa/selftest/cases/meta_ide.py
index 6f10d30dc9..ce7bba401d 100644
--- a/meta/lib/oeqa/selftest/cases/meta_ide.py
+++ b/meta/lib/oeqa/selftest/cases/meta_ide.py
@@ -16,13 +16,14 @@ class MetaIDE(OESelftestTestCase):
     def setUpClass(cls):
         super(MetaIDE, cls).setUpClass()
         bitbake('meta-ide-support')
-        bb_vars = get_bb_vars(['MULTIMACH_TARGET_SYS', 'TMPDIR', 'COREBASE'])
+        bitbake('build-sysroots')
+        bb_vars = get_bb_vars(['MULTIMACH_TARGET_SYS', 'DEPLOY_DIR_IMAGE', 'COREBASE'])
         cls.environment_script = 'environment-setup-%s' % bb_vars['MULTIMACH_TARGET_SYS']
-        cls.tmpdir = bb_vars['TMPDIR']
-        cls.environment_script_path = '%s/%s' % (cls.tmpdir, cls.environment_script)
+        cls.deploydir = bb_vars['DEPLOY_DIR_IMAGE']
+        cls.environment_script_path = '%s/%s' % (cls.deploydir, cls.environment_script)
         cls.corebasedir = bb_vars['COREBASE']
         cls.tmpdir_metaideQA = tempfile.mkdtemp(prefix='metaide')
-        
+
     @classmethod
     def tearDownClass(cls):
         shutil.rmtree(cls.tmpdir_metaideQA, ignore_errors=True)
@@ -49,3 +50,8 @@ class MetaIDE(OESelftestTestCase):
                         msg="Running make failed")
         self.assertEqual(self.project.run_install(), 0,
                         msg="Running make install failed")
+
+    def test_meta_ide_can_run_sdk_tests(self):
+        bitbake('-c populate_sysroot gtk+3')
+        bitbake('build-sysroots')
+        bitbake('-c testsdk meta-ide-support')
-- 
2.30.2

[RFC PATCH 5/6] oeqa/sdk: allow epoxy/galculator tests to run in esdk and direct yocto builds

[Alexander Kanavin]

Other tests already have similar tweaks.

Signed-off-by: Alexander Kanavin <alex@linutronix.de>
---
 meta/lib/oeqa/sdk/cases/buildepoxy.py      | 3 ++-
 meta/lib/oeqa/sdk/cases/buildgalculator.py | 3 ++-
 2 files changed, 4 insertions(+), 2 deletions(-)

diff --git a/meta/lib/oeqa/sdk/cases/buildepoxy.py b/meta/lib/oeqa/sdk/cases/buildepoxy.py
index f69f720cd6..ad08b777f2 100644
--- a/meta/lib/oeqa/sdk/cases/buildepoxy.py
+++ b/meta/lib/oeqa/sdk/cases/buildepoxy.py
@@ -16,7 +16,8 @@ class EpoxyTest(OESDKTestCase):
     Test that Meson builds correctly.
     """
     def setUp(self):
-        if not (self.tc.hasHostPackage("nativesdk-meson")):
+        if not (self.tc.hasHostPackage("nativesdk-meson") or
+                self.tc.hasHostPackage("meson-native")):
             raise unittest.SkipTest("EpoxyTest class: SDK doesn't contain Meson")
 
     def test_epoxy(self):
diff --git a/meta/lib/oeqa/sdk/cases/buildgalculator.py b/meta/lib/oeqa/sdk/cases/buildgalculator.py
index eb3c8ddf39..58ade920c9 100644
--- a/meta/lib/oeqa/sdk/cases/buildgalculator.py
+++ b/meta/lib/oeqa/sdk/cases/buildgalculator.py
@@ -19,7 +19,8 @@ class GalculatorTest(OESDKTestCase):
         if not (self.tc.hasTargetPackage("gtk+3", multilib=True) or \
                 self.tc.hasTargetPackage("libgtk-3.0", multilib=True)):
             raise unittest.SkipTest("GalculatorTest class: SDK don't support gtk+3")
-        if not (self.tc.hasHostPackage("nativesdk-gettext-dev")):
+        if not (self.tc.hasHostPackage("nativesdk-gettext-dev") or
+                self.tc.hasHostPackage("gettext-native")):
             raise unittest.SkipTest("GalculatorTest class: SDK doesn't contain gettext")
 
     def test_galculator(self):
-- 
2.30.2

[RFC PATCH 6/6] oeqa/sdk: drop the nativesdk-python 2.x test

[Alexander Kanavin]

Python 2.x has been EOL for a while, and so this test
never runs.

Signed-off-by: Alexander Kanavin <alex@linutronix.de>
---
 meta/lib/oeqa/sdk/cases/python.py | 11 -----------
 1 file changed, 11 deletions(-)

diff --git a/meta/lib/oeqa/sdk/cases/python.py b/meta/lib/oeqa/sdk/cases/python.py
index a334abce5f..d43354c32a 100644
--- a/meta/lib/oeqa/sdk/cases/python.py
+++ b/meta/lib/oeqa/sdk/cases/python.py
@@ -8,17 +8,6 @@ from oeqa.sdk.case import OESDKTestCase
 from oeqa.utils.subprocesstweak import errors_have_output
 errors_have_output()
 
-class Python2Test(OESDKTestCase):
-    def setUp(self):
-        if not (self.tc.hasHostPackage("nativesdk-python-core") or
-                self.tc.hasHostPackage("python-core-native")):
-            raise unittest.SkipTest("No python package in the SDK")
-
-    def test_python2(self):
-        cmd = "python -c \"import codecs; print(codecs.encode('Uryyb, jbeyq', 'rot13'))\""
-        output = self._run(cmd)
-        self.assertEqual(output, "Hello, world\n")
-
 class Python3Test(OESDKTestCase):
     def setUp(self):
         if not (self.tc.hasHostPackage("nativesdk-python3-core") or
-- 
2.30.2

Re: [OE-core] [RFC PATCH 0/6] (e)SDK workflow directly in a Yocto build

[Paul Eggleton]

Hi Alex

On Wednesday, 22 June 2022 22:33:06 NZDT Alexander Kanavin wrote:
> There's been a recent discussion about how we can make the Yocto SDK
> experience better [1]. One of the ideas was to eliminate the SDK
> as a separate artefact altogether and simply provide everything
> that the SDK and eSDKs do directly in a yocto build. This does not
> mean that people have to 'learn Yocto', but rather that the integrators
> should provide a well-functioning sstate cache infrastructure (same as
> with minimal eSDK, really), and a few wrapper scripts for setting up the
> build and the SDK environment that run layer setup and bitbake behind the
> scenes.

FWIW I think this is quite clever - well done :)

One question though:

> 2. Run:
> $ bitbake meta-ide-support
> $ bitbake -c populate_sysroot gtk+3
> (or any other target or native item that the application developer would
> need) 
> $ bitbake populate-sysroots

Should this have been "build-sysroots"? "populate-sysroots" doesn't seem to be 
a valid target. It looks like this is in the SDK manual as well.

Cheers
Paul

Re: [OE-core] [RFC PATCH 0/6] (e)SDK workflow directly in a Yocto build

[Alexander Kanavin]

On Mon, 10 Oct 2022 at 10:23, Paul Eggleton
<bluelightning@bluelightning.org> wrote:
> > 2. Run:
> > $ bitbake meta-ide-support
> > $ bitbake -c populate_sysroot gtk+3
> > (or any other target or native item that the application developer would
> > need)
> > $ bitbake populate-sysroots
>
> Should this have been "build-sysroots"? "populate-sysroots" doesn't seem to be
> a valid target. It looks like this is in the SDK manual as well.

Yes, of course. It's a simple typo, I'll fix the docs.

Alex

Re: [OE-core] [RFC PATCH 0/6] (e)SDK workflow directly in a Yocto build

[Leon Woestenberg]

Hello Alexander,

On Wed, Jun 22, 2022 at 12:33 PM Alexander Kanavin
<alex.kanavin@gmail.com> wrote:
>
> There's been a recent discussion about how we can make the Yocto SDK
> experience better [1]. One of the ideas was to eliminate the SDK
> as a separate artefact altogether and simply provide everything
> that the SDK and eSDKs do directly in a yocto build.
>
> So without further ado, here's how you get a 'SDK' with this set of patches:
>
Thanks for this work!  I like this approach.

Regards,

Leon.

Re: [OE-core] [RFC PATCH 0/6] (e)SDK workflow directly in a Yocto build

[Alexander Kanavin]

Cheers - try the new layer setup and config management tools too :-)

Alex

On Thu, 13 Oct 2022 at 10:44, Leon Woestenberg <leon@sidebranch.com> wrote:
>
> Hello Alexander,
>
> On Wed, Jun 22, 2022 at 12:33 PM Alexander Kanavin
> <alex.kanavin@gmail.com> wrote:
> >
> > There's been a recent discussion about how we can make the Yocto SDK
> > experience better [1]. One of the ideas was to eliminate the SDK
> > as a separate artefact altogether and simply provide everything
> > that the SDK and eSDKs do directly in a yocto build.
> >
> > So without further ado, here's how you get a 'SDK' with this set of patches:
> >
> Thanks for this work!  I like this approach.
>
> Regards,
>
> Leon.