GNU bug report logs - #61765
custom toolchain blog post

Previous Next

Full log

View this message in rfc822 format

From: Ludovic Courtès <ludo <at> gnu.org>
To: Mitchell Schmeisser <mitchellschmeisser <at> librem.one>
Cc: 61765 <at> debbugs.gnu.org
Subject: [bug#61765] custom toolchain blog post
Date: Sat, 11 Mar 2023 13:11:55 +0100

Hi Mitchel,

(Please keep the issue Cc’d.)

Apologies for the delay!

Mitchell Schmeisser <mitchellschmeisser <at> 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 <at> 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’.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.