Re: [PATCH v3 0/4] multiarch support

[Uladzimir Bely <ubely@ilbers.de>]

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.