From: "Ludovic Courtès" <ludo@gnu.org>
To: Christopher Baines <mail@cbaines.net>
Cc: 72136@debbugs.gnu.org
Subject: [bug#72136] [PATCH 1/2] gnu: coreutils-minimal: Don't support targets with no system.
Date: Thu, 18 Jul 2024 11:33:49 +0200 [thread overview]
Message-ID: <87ikx3vybm.fsf@gnu.org> (raw)
In-Reply-To: <7d092a3734bd2f988e03bfb28fb0ca6a0302cc86.1721119509.git.mail@cbaines.net> (Christopher Baines's message of "Tue, 16 Jul 2024 09:45:08 +0100")
Hello,
Christopher Baines <mail@cbaines.net> skribis:
> Since I believe coreutils-minimal will fail to build for these targets, this
> will catch this early and display a clear message for both this package and
> packages using it as an input.
>
> * gnu/packages/base.scm (coreutils-minimal)[native-inputs]: Check the target
> if there is one.
>
> Change-Id: Id37cf6ac0b63226261a85a00699dfd06188c1475
[...]
> + (native-inputs
> + (begin
> + (let ((target (%current-target-system)))
> + (when target
> + (unless (platform-system (lookup-platform-by-target target))
> + (raise
> + (condition
> + (&package-unsupported-target-error
> + (package this-package)
> + (target target)))))))
> + '()))
I understand the rationale, but this raises a few issues IMO:
1. This is abusing the ‘native-inputs’ field.
2. It’s the kind of thing that should be purely declarative, much like
‘supported-systems’.
3. So far, we do not keep track of the supported cross-compilation
targets of each package, and I think it’s probably better that way:
the set of cross-compilation targets is pretty much open-ended and
we only check them on a best-effort basis, for select packages
(typically those listed in ‘packages-to-cross-build’ in (gnu ci)
and/or ‘etc/release-manifest.scm’). I think we’d rather not start
annotating packages for supported cross-compilation target.
That said, the initial problem remains: how can we ensure that the Data
Service does not attempt to compute cross-build derivations that don’t
make sense, such as Coreutils on bare-metal targets like ‘avr’?
My take is that we should bake knowledge about what makes sense to be
tested somewhere. It could be either arranging so (gnu ci) can be used
by the Data Service (it’s currently used by Cuirass), or
‘etc/release-manifest.scm’, or even just a hard-coded listed of
supported targets—we’re talking about a list of ten triplets or so,
that’s okay.
Or perhaps there’s room for something nicer in (guix platforms), but I
don’t see how we could determine whether a given package is eligible for
a bare-metal target.
Thoughts?
Ludo’.
prev parent reply other threads:[~2024-07-18 9:37 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-07-16 8:42 [bug#72136] [PATCH 0/2] Guard against producing derivations for platforms with no system Christopher Baines
2024-07-16 8:45 ` [bug#72136] [PATCH 1/2] gnu: coreutils-minimal: Don't support targets " Christopher Baines
2024-07-16 8:45 ` [bug#72136] [PATCH 2/2] gnu: bash-minimal: " Christopher Baines
2024-07-18 9:33 ` Ludovic Courtès [this message]
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
List information: https://guix.gnu.org/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87ikx3vybm.fsf@gnu.org \
--to=ludo@gnu.org \
--cc=72136@debbugs.gnu.org \
--cc=mail@cbaines.net \
/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.
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/guix.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).