Buildroot Archive on lore.kernel.org
 help / color / mirror / Atom feed
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

  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