[bug#61765] custom toolchain blog post

[Mitchell Schmeisser via Guix-patches via <guix-patches@gnu.org>]

[-- Attachment #1: Type: text/plain, Size: 4749 bytes --]

Hi Ludo,
> 
> OK.  To put it differently, a typical POSIX program won’t work on
> Zephyr; programs have to target the Zephyr interfaces, right?

This is mostly correct. I think a lot of my conceptual difficulties come from the fact that west/zephyr try to tackle the issues of software deployment and dependency management at the project level. What I mean to say is that in the rest of the software world we have things like auto tools or pkg-config to help with component composition but Zephyr tries to do all composition through several thousands of lines of cmake. Every bit as complex as the kernel kconfig but even more so since modules can be scattered across the file system.
One of the selling points of zephyr is that your application is abstracted from the hardware and can run on multiple boards without modification. However to make this happen you need to do a lot of work on the application side. 
Below you can see an example. You have to provide the proper kernel config for every target you want to support.
https://github.com/zephyrproject-rtos/zephyr/tree/main/samples/net/mqtt_publisher

Using guix there may be a more elegant solution to these problems but maybe not.

Thank you for all your feedback,
Mitchell


> On Mar 11, 2023, at 7:12 AM, Ludovic Courtès <ludo@gnu.org> 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 #2: Type: text/html, Size: 8197 bytes --]