Message ID | 20230224142432.3767746-1-adriaan.schmidt@siemens.com |
---|---|
Headers | show |
Series | multiarch support | expand |
On 03.03.23 08:31, Uladzimir Bely wrote: > In mail from Friday, 24 February 2023 17:24:28 +03 user Adriaan Schmidt wrote: >> This adds `<package>-compat` and `<package>-native` bitbake >> targets to all recipes inheriting dpkg-base. >> >> The new -compat build variant replaces the old compat mechanism. >> Note that `ISAR_ENABLE_COMPAT_ARCH="1"` is still required to >> ensure that the bootstrap and buildchroot is prepared correctly. >> >> Regarding testing of the new features: >> - we have (limited) testing of compat, by adding `hello-isar-compat` to >> amd64 and arm64 builds. >> - currently no testing of native. There are two main use cases for the >> feature: - SDK that needs `<package>-native`. This could be turned into a >> test easily, by setting/appending SDK_INSTALL. Would require a new option >> in testsuite, similar to `image_install` introduced in 57a0ade9a. - A build >> tool that is provided by a recipe, when using it in cross compilation. E.g. >> if someone needed a patched cmake, they would write cmake.bb, and >> applications that need it would (in case cross compilation is enabled) >> DEPEND+="cmake-native". Or, another real-world example from a downstream >> layer: packaging applications with goreleaser, which is not found in the >> Debian apt repos. Instead, I'm fetching it via a dpkg-prebuilt recipe, >> written to support multiple architectures (architecture is part of the >> download URL). Now if I want to cross compile go applications, they >> DEPEND+="goreleaser-native", and DEBIAN_BUILD_DEPENDS_append=", >> goreleaser:native". >> These cases are more complex, but maybe we can find an example along >> those lines and add it to meta-isar. >> >> As testing of the native feature would (in the simple case) need an >> extension of the test classes (for SDK_INSTALL), or introduce something >> completely new into meta-isar, I'd like to do that after discussion, in >> a later series. >> >> Adriaan >> >> changes since v2: >> - fixed a bug that completely broke things for targets without a compat >> arch (e.g., i386). The compat variant of packages is now only available >> when it can actually be built. >> - the native variant is only generated if it differs from the target. >> If DISTRO_ARCH==HOST_ARCH, then `<package>-native` is automatically >> provided by the target package. >> - also do the bitbake-target->debian-package transformation on SDK_INSTALL >> - fix compat packages in testsuite: when we add hello-isar-compat, we >> need to remove hello-isar. >> >> changes since v1: >> - fixed an issue that prevented arch overrides of >> ISAR_ENABLE_COMPAT_ARCH, which is used in testsuite >> - added `-native` expansion to contents of IMAGE_INSTALL >> - documentation in user_manual >> >> >> Adriaan Schmidt (4): >> bitbake.conf: use PACKAGE_ARCH in overrides >> add multiarch support >> remove obsolete compat-arch override >> doc: add compat/native targets to user manual >> >> doc/user_manual.md | 19 ++-- >> .../recipes-app/hello-isar/hello-isar.bb | 3 - >> meta-isar/recipes-app/libhello/libhello.bb | 3 - >> .../recipes-app/samefile/samefile_2.14.bb | 2 +- >> meta/classes/compat.bbclass | 40 +++++++++ >> meta/classes/debianize.bbclass | 2 +- >> meta/classes/dpkg-base.bbclass | 1 + >> meta/classes/image.bbclass | 4 +- >> meta/classes/multiarch.bbclass | 88 +++++++++++++++++++ >> meta/classes/native.bbclass | 10 +++ >> meta/classes/sdk.bbclass | 2 +- >> meta/conf/bitbake.conf | 6 +- >> .../isar-bootstrap/isar-bootstrap.inc | 2 + >> .../sbuild-chroot/sbuild-chroot.inc | 14 +-- >> testsuite/cibuilder.py | 4 + >> 15 files changed, 174 insertions(+), 26 deletions(-) >> create mode 100644 meta/classes/compat.bbclass >> create mode 100644 meta/classes/multiarch.bbclass >> create mode 100644 meta/classes/native.bbclass > > The patchset passes CI (there was a delay in testing due to internal problems > with it) and is ready for merge. > > I'd like just to remind that Jan requested mentioning changes in RECIPE-API- > CHANGELOG, not only in user_manual. > > If this point is still valid, we need v4; if not, we could proceed with > patchset merge. > The point remains valid due to patch 3, but I suppose we can quickly add a related patch for the changelog on top. Adriaan? Jan
Kiszka, Jan (T CED), Freitag, 3. März 2023 08:40: > On 03.03.23 08:31, Uladzimir Bely wrote: > > In mail from Friday, 24 February 2023 17:24:28 +03 user Adriaan Schmidt > wrote: > >> This adds `<package>-compat` and `<package>-native` bitbake > >> targets to all recipes inheriting dpkg-base. > >> > >> The new -compat build variant replaces the old compat mechanism. > >> Note that `ISAR_ENABLE_COMPAT_ARCH="1"` is still required to > >> ensure that the bootstrap and buildchroot is prepared correctly. > >> > >> Regarding testing of the new features: > >> - we have (limited) testing of compat, by adding `hello-isar-compat` to > >> amd64 and arm64 builds. > >> - currently no testing of native. There are two main use cases for the > >> feature: - SDK that needs `<package>-native`. This could be turned into a > >> test easily, by setting/appending SDK_INSTALL. Would require a new option > >> in testsuite, similar to `image_install` introduced in 57a0ade9a. - A > build > >> tool that is provided by a recipe, when using it in cross compilation. > E.g. > >> if someone needed a patched cmake, they would write cmake.bb, and > >> applications that need it would (in case cross compilation is enabled) > >> DEPEND+="cmake-native". Or, another real-world example from a downstream > >> layer: packaging applications with goreleaser, which is not found in the > >> Debian apt repos. Instead, I'm fetching it via a dpkg-prebuilt recipe, > >> written to support multiple architectures (architecture is part of the > >> download URL). Now if I want to cross compile go applications, they > >> DEPEND+="goreleaser-native", and DEBIAN_BUILD_DEPENDS_append=", > >> goreleaser:native". > >> These cases are more complex, but maybe we can find an example along > >> those lines and add it to meta-isar. > >> > >> As testing of the native feature would (in the simple case) need an > >> extension of the test classes (for SDK_INSTALL), or introduce something > >> completely new into meta-isar, I'd like to do that after discussion, in > >> a later series. > >> > >> Adriaan > >> > >> changes since v2: > >> - fixed a bug that completely broke things for targets without a compat > >> arch (e.g., i386). The compat variant of packages is now only available > >> when it can actually be built. > >> - the native variant is only generated if it differs from the target. > >> If DISTRO_ARCH==HOST_ARCH, then `<package>-native` is automatically > >> provided by the target package. > >> - also do the bitbake-target->debian-package transformation on SDK_INSTALL > >> - fix compat packages in testsuite: when we add hello-isar-compat, we > >> need to remove hello-isar. > >> > >> changes since v1: > >> - fixed an issue that prevented arch overrides of > >> ISAR_ENABLE_COMPAT_ARCH, which is used in testsuite > >> - added `-native` expansion to contents of IMAGE_INSTALL > >> - documentation in user_manual > >> > >> > >> Adriaan Schmidt (4): > >> bitbake.conf: use PACKAGE_ARCH in overrides > >> add multiarch support > >> remove obsolete compat-arch override > >> doc: add compat/native targets to user manual > >> > >> doc/user_manual.md | 19 ++-- > >> .../recipes-app/hello-isar/hello-isar.bb | 3 - > >> meta-isar/recipes-app/libhello/libhello.bb | 3 - > >> .../recipes-app/samefile/samefile_2.14.bb | 2 +- > >> meta/classes/compat.bbclass | 40 +++++++++ > >> meta/classes/debianize.bbclass | 2 +- > >> meta/classes/dpkg-base.bbclass | 1 + > >> meta/classes/image.bbclass | 4 +- > >> meta/classes/multiarch.bbclass | 88 +++++++++++++++++++ > >> meta/classes/native.bbclass | 10 +++ > >> meta/classes/sdk.bbclass | 2 +- > >> meta/conf/bitbake.conf | 6 +- > >> .../isar-bootstrap/isar-bootstrap.inc | 2 + > >> .../sbuild-chroot/sbuild-chroot.inc | 14 +-- > >> testsuite/cibuilder.py | 4 + > >> 15 files changed, 174 insertions(+), 26 deletions(-) > >> create mode 100644 meta/classes/compat.bbclass > >> create mode 100644 meta/classes/multiarch.bbclass > >> create mode 100644 meta/classes/native.bbclass > > > > The patchset passes CI (there was a delay in testing due to internal > problems > > with it) and is ready for merge. > > > > I'd like just to remind that Jan requested mentioning changes in RECIPE- > API- > > CHANGELOG, not only in user_manual. > > > > If this point is still valid, we need v4; if not, we could proceed with > > patchset merge. > > > > The point remains valid due to patch 3, but I suppose we can quickly add > a related patch for the changelog on top. Adriaan? I'm already preparing v4 with cosmetic changes that came up in review (mainly dropping the expand=True in calls to getVar()). I will add a note to the recipe api changelog. Adriaan > Jan > > -- > Siemens AG, Technology > Competence Center Embedded Linux