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