custom toolchain blog post

Here is a rough draft of my toolchain post.

I hope it can make an interesting contribution to the Guix literature.

- Mitchell

From 4f6c43091ffd67cdbc5f041e496f61bc8a06070e Mon Sep 17 00:00:00 2001

---

website/posts/custom-toolchains-with-guix.md | 557 +++++++++++++++++++

1 file changed, 557 insertions(+)

create mode 100644 website/posts/custom-toolchains-with-guix.md

Hello Mitchell,

Mitchell Schmeisser <mitchellschmeisser@librem.one> skribis:

Yay, definitely!

This looks great to me! It’s useful insight for anyone who might want

to add a cross-compilation target to Guix or simply learn how this is

implemented.

You can remove the table of contents and all the HTML snippets that

pandoc added—I don’t think that works as expected with Haunt/CommonMark.

You can drop the heading.

We want blog posts to be widely accessible so I would recommend

providing more context in the intro. In particular, I’d suggest:

1. Mentioning that Guix supports cross-compilation (not everyone is

aware of that), with a link to

https://guix.gnu.org/en/manual/en/html_node/Cross_002dCompilation.html.

2. Adding a couple of sentences saying what Zephyr is (I didn’t know

about it before :-)).

3. Saying a few words as to why Zephyr uses a GCC fork.

4. Clearly stating that you added support for cross-compilation to

Zephyr with Guix in a channel, linking to said channel, and that

this is what the remainder of the post will describe.

You can check out posts at https://guix.gnu.org/blog for inspiration.

I’d suggest not using fixed-width font (backquotes) for proper nouns;

you can write “glibc” or “the GNU C Library (glibc)”, “Binutils” or “the

GNU Binary Utilities (Binutils)”, etc.

Code snippets should be written like this, without leading indentation:

```scheme

(define …)

```

This will enable syntax highlighting.

Likewise:

```

guix build foo

```

s/it's/its/

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?

It would be great if you could finish with a short conclusion stating,

for instance, the key takeaway message, lessons learned, and/or your

thoughts on how this could benefit others in the broader community.

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?

Could you send an updated patch?

Thanks for contributing this article!

Ludo’.

tags 61765 + moreinfo

quit

Hi Mitchel,

(Please keep the issue Cc’d.)

Apologies for the delay!

Mitchell Schmeisser <mitchellschmeisser@librem.one> skribis:

OK. To put it differently, a typical POSIX program won’t work on

Zephyr; programs have to target the Zephyr interfaces, right?

Or rather:

guix build --target=arm-zephyr-eabi k64f-hello-world

?

Woow. :-)

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

Hi Ludo,

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.

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

Thank you for all your feedback,

Mitchell

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,

Mitchell Schmeisser <mitchellschmeisser@librem.one> skribis:

No tips, other than making sure to untabify. :-)

[...]

Applied, and finally published:

https://guix.gnu.org/en/blog/2023/building-toolchains-with-guix/

Thank you!

Ludo’.

close 61765

quit

Ah I’m so honored, thank you for the encouragement!

-Mitchell