Ludovic Courtès <l...@gnu.org> writes: >>>> From 940c03c7dcddec019e27f6eb1470aeab4db57799 Mon Sep 17 00:00:00 2001 >>>> From: Marius Bakke <mba...@fastmail.com> >>>> Date: Thu, 20 Oct 2016 17:26:52 +0100 >>>> Subject: [PATCH] gnu: Add grub-efi. >>>> >>>> * gnu/packages/grub.scm (grub-efi): New variable. >>> >>> [...] >>> >>>> + (name "grub-efi") >>>> + (synopsis (string-append (package-synopsis grub) " (UEFI version)")) >>> >>> Please use a literal string for ‘synopsis’; use of ‘string-append’ like >>> this prevents i18n. >>> >>>> + `(#:tests? #f ; FIXME: 40 failures, 24 skipped, 17 passed. >>> >>> It would be good to investigate, especially if the tests pass in the >>> ‘grub’ package. >>> >>> Also, what’s the rationale for making ‘grub-efi’ separate instead of >>> incorporating the changes in ‘grub’ proper? Are there issues around the >>> portability of ‘efibootmgr’, or an increased closure size? >> >> This is a good point. The only difference with "--with-platform=efi" is >> that another directory is created in place of the i386-pc directory. It >> is perfectly possible to build multiple platforms and copying the >> platform-specific stuff to $out/lib -- grub will pick the correct >> platform at runtime. This is what the Gentoo ebuild does. > > Are you saying that a GRUB compiled with UEFI support will no longer > work out-of-the-box on non-UEFI machines, unless platform-specific stuff > is moved like you suggest?
Ha, no, it was just a long-winded and intoxicated way of saying what you proposed should work fine. :) The platform-specific stuff ends up in $out/lib/<platform> by default, so there won't be any conflicts there, and grub-install will pick the correct one automatically. That approach is better, I think. Will have a go at it. The tricky part is invoking the 'configure, 'build and 'install steps with appropriate arguments for each platform in the grub expression, but that does not sound too difficult.
signature.asc
Description: PGP signature
