GNU bug report logs - #61765
custom toolchain blog post

Previous Next

Full log

Message #22 received at 61765 <at> debbugs.gnu.org (full text, mbox):

From: Mitchell Schmeisser <mitchellschmeisser <at> librem.one>
To: Ludovic Courtès <ludo <at> gnu.org>
Cc: 61765 <at> debbugs.gnu.org
Subject: Re: bug#61765: custom toolchain blog post
Date: Mon, 13 Mar 2023 09:52:32 -0400

[Message part 1 (text/plain, inline)]

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 <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’.

[0001-website-custom-toolchains-with-guix-Code-fix.patch (text/x-patch, attachment)]

[0002-website-custom-toolchains-with-guix-Update-reference.patch (text/x-patch, attachment)]

Previous Next

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