From: Jan Kiszka <jan.kiszka@siemens.com>
To: Uladzimir Bely <ubely@ilbers.de>, isar-users@googlegroups.com
Cc: Adriaan Schmidt <adriaan.schmidt@siemens.com>
Subject: Re: [PATCH v3 0/4] multiarch support
Date: Fri, 3 Mar 2023 08:39:52 +0100 [thread overview]
Message-ID: <3bf9eb9a-aacb-8517-9ce4-57ff94cbdfbc@siemens.com> (raw)
In-Reply-To: <5512759.ZASKD2KPVS@hp>
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
--
Siemens AG, Technology
Competence Center Embedded Linux
next prev parent reply other threads:[~2023-03-03 7:39 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-02-24 14:24 Adriaan Schmidt
2023-02-24 14:24 ` [PATCH v3 1/4] bitbake.conf: use PACKAGE_ARCH in overrides Adriaan Schmidt
2023-02-24 14:24 ` [PATCH v3 2/4] add multiarch support Adriaan Schmidt
2023-02-24 14:24 ` [PATCH v3 3/4] remove obsolete compat-arch override Adriaan Schmidt
2023-02-24 14:24 ` [PATCH v3 4/4] doc: add compat/native targets to user manual Adriaan Schmidt
2023-03-03 7:31 ` [PATCH v3 0/4] multiarch support Uladzimir Bely
2023-03-03 7:39 ` Jan Kiszka [this message]
2023-03-03 8:10 ` Schmidt, Adriaan
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=3bf9eb9a-aacb-8517-9ce4-57ff94cbdfbc@siemens.com \
--to=jan.kiszka@siemens.com \
--cc=adriaan.schmidt@siemens.com \
--cc=isar-users@googlegroups.com \
--cc=ubely@ilbers.de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox