From: "Ludovic Courtès" <ludo@gnu.org>
To: Mitchell Schmeisser <mitchellschmeisser@librem.one>
Cc: 61765@debbugs.gnu.org
Subject: [bug#61765] custom toolchain blog post
Date: Sat, 11 Mar 2023 13:11:55 +0100 [thread overview]
Message-ID: <87zg8jwkqc.fsf@gnu.org> (raw)
In-Reply-To: <87k003xgs0.fsf@librem.one> (Mitchell Schmeisser's message of "Mon, 27 Feb 2023 10:35:43 -0500")
Hi Mitchel,
(Please keep the issue Cc’d.)
Apologies for the delay!
Mitchell Schmeisser <mitchellschmeisser@librem.one> skribis:
>> One thing that’s not clear to me: with this in place, can you do “guix
>> build --target=arm-zephyr-eabi hello”, for instance? If not, what’s
>> missing to support it?
>
> You cannot. I do not know how to describe it in a succinct way but
> suffice to say the applications need to know they are targeting Zephyr
> when they are written. The application will include a `prj.conf` which
> is analogous to a custom defconfig in the Linux kernel.
> Either in this file, or somewhere in the CMakeLists.txt a `BOARD`
> variable is set to specify a specific board definition.
> These board definitions contain information about the architecture and
> the CMake scripts themselves pick the toolchain.
>
> It's not that it's impossible to implement something like `guix build
> --target=arm-zephyr-eabi k64f-hello-world` but the k64f-hello-world
> would be written in such a way that the target is implicit in the
> package.
OK. To put it differently, a typical POSIX program won’t work on
Zephyr; programs have to target the Zephyr interfaces, right?
> The way I envision the `--target/system` flags being used in this
> context is `guix build --target=arm-linux-gnueabihf k64f-hello-world`
> which will still produce the correct firmware but will allow the
> firmware to be staged to another machine which will be responsible for
> the final deployment over some transport.
Or rather:
guix build --target=arm-zephyr-eabi k64f-hello-world
?
>> I wonder if it would be worth mentioning
>> <https://guix.gnu.org/manual/en/html_node/Platforms.html> too, and how
>> one would go about adding a module. WDYT?
>
> I considered trying to add Zephyr platforms but I'm not sure it's worth
> the effort.
> In addition to the patch to the website I attached another post(in org)
> which describes how I integrated this toolchain into the Guix
> infrastructure to allow defining firmware packages.
> Maybe there will be additional information in there which can help you
> understand where I'm going with all of this.
>
> There will be a part 3 (and possibly more) about how to practically use
> this stuff in a real project.
Woow. :-)
> From 0920ec7d951354c94c3da277d58e54b587522622 Mon Sep 17 00:00:00 2001
> From: Mitchell Schmeisser <mitchellschmeisser@librem.one>
> Date: Mon, 27 Feb 2023 10:20:32 -0500
> Subject: [PATCH] website: Add toolchain blog post
>
> website/blog/custom-toolchains-with-guix.md: New file
I pushed it under the drafts directory for now, to leave others a bit
more time to comment before we publish. I followed up with a commit
editing things a bit, mostly fixing typographical issues,
spelling/capitalization, code formatting, and removing tabs.
https://git.savannah.gnu.org/cgit/guix/guix-artwork.git/tree/website/drafts/custom-toolchains-with-guix.md
(BTW, I made slight modifications to some of the code snippets to! One
package was using (append (list …) (package-native-inputs …)), which
really works “by chance” I guess; you should use ‘modify-inputs’
instead.)
Let me know if anything’s amiss!
Thanks,
Ludo’.
next prev parent reply other threads:[~2023-03-11 12:13 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-02-24 18:51 [bug#61765] custom toolchain blog post Mitchell Schmeisser via Guix-patches via
2023-02-27 12:50 ` Ludovic Courtès
2023-02-27 15:35 ` Mitchell Schmeisser via Guix-patches
2023-03-11 12:11 ` Ludovic Courtès [this message]
2023-03-11 16:50 ` Mitchell Schmeisser via Guix-patches via
2023-03-13 13:52 ` Mitchell Schmeisser via Guix-patches via
2023-03-15 14:45 ` Ludovic Courtès
2023-03-16 1:55 ` Mitchell Schmeisser via Guix-patches via
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=87zg8jwkqc.fsf@gnu.org \
--to=ludo@gnu.org \
--cc=61765@debbugs.gnu.org \
--cc=mitchellschmeisser@librem.one \
/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 external index
https://git.savannah.gnu.org/cgit/guix.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.