guix-patches
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[bug#61765] custom toolchain blog post


From: Mitchell Schmeisser
Subject: [bug#61765] custom toolchain blog post
Date: Mon, 13 Mar 2023 09:52:32 -0400
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.6.0

Here are two patches with minor fixes.

Sorry about the code formatting... Does anyone have any tips for getting emacs to format scheme code in markdown?


Thanks,

Mitchell


On 3/11/23 07:11, Ludovic Courtès wrote:
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’.

Attachment: 0001-website-custom-toolchains-with-guix-Code-fix.patch
Description: Text Data

Attachment: 0002-website-custom-toolchains-with-guix-Update-reference.patch
Description: Text Data


reply via email to

[Prev in Thread] Current Thread [Next in Thread]