From: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
To: "Yann E. MORIN" <yann.morin.1998@free.fr>
Cc: Kory Maincent <kory.maincent@bootlin.com>, buildroot@buildroot.org
Subject: Re: [Buildroot] [PATCH 1/8] boot/grub2: add support to build multiple Grub2 configurations in the same build
Date: Sat, 18 Sep 2021 10:50:42 +0200 [thread overview]
Message-ID: <20210918105042.7a0887cd@windsurf> (raw)
In-Reply-To: <20210917212429.GY1053080@scaer>
Hello Yann,
On Fri, 17 Sep 2021 23:24:29 +0200
"Yann E. MORIN" <yann.morin.1998@free.fr> wrote:
> What you forgot to state in bold fat characters here, is that we can no
> longer use autotools-package as a consequence of this multi-build, and
> that we have to resort to generic-pacakge and a partial duplication of
> the autotools-infra.
>
> This is not very nice... :-(
Indeed, but...
> IIRC, we had a similar problem with barbox, where we had to build two
> images for it, so we ended up duplicating the package, where the
> top-most boot/barebox/barebox.mk defines a minimalist barebox-package
> infra, and the barebox and barebox-aux are two barebox-package:
>
> boot/barebox/
> ├── barebox/
> │ ├── barebox.hash -> ../barebox.hash
> │ ├── barebox.mk
> │ └── Config.in
> ├── barebox-aux/
> │ ├── barebox-aux.hash -> ../barebox.hash
> │ ├── barebox-aux.mk
> │ └── Config.in
> ├── barebox.hash
> ├── barebox.mk
> └── Config.in
>
> If I understand correctly, we are in a similar situation with grub2, and
> there are only ever at most two "platforms" we can build, and it does
> not look like it will ever change:
Nope, that is not correct.
> i386:
> BR2_TARGET_GRUB2_I386_PC
> BR2_TARGET_GRUB2_I386_EFI
>
> x86_64:
> BR2_TARGET_GRUB2_I386_EFI
> BR2_TARGET_GRUB2_X86_64_EFI
On x86-64, we can have:
BR2_TARGET_GRUB2_I386_PC
BR2_TARGET_GRUB2_I386_EFI
BR2_TARGET_GRUB2_X86_64_EFI
to cover legacy BIOS platforms (32-bit), 32-bit EFI BIOS and 64-bit EFI
BIOS. Dans this is precisely the use-case we are in fact interested in.
So that means we would need 3 Grub packages, which is the reason why it
felt much more reasonable to just extend the grub2 package itself.
> > GRUB2_CONF_OPTS = \
> > - --target=$(GRUB2_TARGET) \
> > - --with-platform=$(GRUB2_PLATFORM) \
> > + --host=$(GNU_TARGET_NAME) \
> > + --build=$(GNU_HOST_NAME) \
> > + --target=$(GRUB2_$(call UPPERCASE,$(tuple))_TARGET) \
> > + --with-platform=$(GRUB2_$(call UPPERCASE,$(tuple))_PLATFORM) \
>
> --target=$(GRUB2_TARGET_$(tuple))
> --with-platform=$(GRUB2_PLATFORM_$(tuple)) \
>
> However, I don't like macros that are implicitly parameterised. We've
> gone in quite some changes in the past to fix similar cases (e.g. in the
> download infra).
Ah, yes, I missed that during the review, indeed the fact that we
reference $(tuple) in GRUB2_CONF_OPTS without it being an argument is a
bit annoying.
> So, I'd write a real parameterised marco:
>
> # $(1): tuple blablabla...
> GRUB2_CONF_OPTS = \
> --host=$(GNU_TARGET_NAME) \
> --target=$(GRUB2_TARGET_$(1)) \
> --with-platform=$(GRUB2_PLATFORM_$(1)) \
> [...]
>
> $(foreach tuple, $(GRUB2_TUPLES_y), \
> [...] \
> ../configure $(call GRUB2_CONF_OPTS,$(tuple))
Or, just do:
../configure $(GRUB2_CONF_OPTS) \
--target=... \
--with-platform=...
I.e, keep out of GRUB2_CONF_OPTS the options that are parameterized.
> > -$(eval $(autotools-package))
> > +$(eval $(generic-package))
>
> This is my main problem: we're mostly duplicating bits and pieces of the
> autotolls-package infra, which means we *will* fall behind very quickly
> when we have to update said infra, and those changes will not percolate
> to this grub2 package.
That is true, but on the other hand, grub2 is not the typical
user-space autotools package either.
See the stack of crap that we have to pass to make it work:
GRUB2_CONF_ENV = \
CPP="$(TARGET_CC) -E" \
TARGET_CC="$(TARGET_CC)" \
CFLAGS="$(TARGET_CFLAGS) -Os" \
TARGET_CFLAGS="$(TARGET_CFLAGS) -Os" \
CPPFLAGS="$(TARGET_CPPFLAGS) -Os -fno-stack-protector" \
TARGET_CPPFLAGS="$(TARGET_CPPFLAGS) -Os -fno-stack-protector" \
TARGET_LDFLAGS="$(TARGET_LDFLAGS) -Os" \
TARGET_NM="$(TARGET_NM)" \
TARGET_OBJCOPY="$(TARGET_OBJCOPY)" \
TARGET_STRIP="$(TARGET_CROSS)strip"
GRUB2_CONF_OPTS = \
--target=$(GRUB2_TARGET) \
--with-platform=$(GRUB2_PLATFORM) \
--prefix=/ \
--exec-prefix=/ \
--disable-grub-mkfont \
--enable-efiemu=no \
ac_cv_lib_lzma_lzma_code=no \
--enable-device-mapper=no \
--enable-libzfs=no \
--disable-werror
Including the passing of --target, custom --prefix, custom
--exec-prefix.
So even though we do use autotools-package, it's not like we don't
already have to play quite a few tricks to get it to do the right thing
with the weirdness of grub2.
Best regards,
Thomas
--
Thomas Petazzoni, co-owner and CEO, Bootlin
Embedded Linux and Kernel engineering and training
https://bootlin.com
_______________________________________________
buildroot mailing list
buildroot@lists.buildroot.org
https://lists.buildroot.org/mailman/listinfo/buildroot
next prev parent reply other threads:[~2021-09-18 8:50 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-09-14 9:34 [Buildroot] [PATCH 0/8] Add support for ISO9660 image compatible with Legacy and EFI BIOS Kory Maincent
2021-09-14 9:34 ` [Buildroot] [PATCH 1/8] boot/grub2: add support to build multiple Grub2 configurations in the same build Kory Maincent
2021-09-17 21:24 ` Yann E. MORIN
2021-09-18 8:50 ` Thomas Petazzoni [this message]
2021-09-18 9:54 ` Yann E. MORIN
2021-09-14 9:34 ` [Buildroot] [PATCH 2/8] package/xorriso: build host variant with zlib support Kory Maincent
2021-09-17 19:52 ` Yann E. MORIN
2021-09-14 9:34 ` [Buildroot] [PATCH 3/8] fs/iso9660: switch from cdrkit to xorriso to build ISO9660 images Kory Maincent
2021-09-17 20:17 ` Yann E. MORIN
2021-09-14 9:34 ` [Buildroot] [PATCH 4/8] fs/iso9660: add support to Grub EFI bootloader in the image Kory Maincent
2021-09-18 12:19 ` Yann E. MORIN
2021-09-14 9:34 ` [Buildroot] [PATCH 5/8] fs/iso9660: add support for hybrid image using Grub bootloader on BIOS and EFI Kory Maincent
2021-09-14 9:34 ` [Buildroot] [PATCH 6/8] support/testing/infra/emulator.py: update encoding when calling qemu Kory Maincent
2021-09-14 9:34 ` [Buildroot] [PATCH 7/8] package/edk2-images: new package Kory Maincent
2021-09-17 13:43 ` D. Olsson via buildroot
2021-09-17 14:14 ` Thomas Petazzoni
2021-09-17 19:24 ` Yann E. MORIN
2021-09-14 9:34 ` [Buildroot] [PATCH 8/8] support/testing/tests/fs/test_iso9660.py: add support to test using EFI BIOS Kory Maincent
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=20210918105042.7a0887cd@windsurf \
--to=thomas.petazzoni@bootlin.com \
--cc=buildroot@buildroot.org \
--cc=kory.maincent@bootlin.com \
--cc=yann.morin.1998@free.fr \
/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