[v3,0/4] multiarch support

Message ID 20230224142432.3767746-1-adriaan.schmidt@siemens.com
Headers show
Series multiarch support | expand

Message

Schmidt, Adriaan Feb. 24, 2023, 2:24 p.m. UTC
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

Comments

Jan Kiszka March 3, 2023, 7:39 a.m. UTC | #1
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
Schmidt, Adriaan March 3, 2023, 8:10 a.m. UTC | #2
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