From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mp10.migadu.com ([2001:41d0:2:4a6f::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by ms9.migadu.com with LMTPS id EGcYFpCxDGQ8UQAASxT56A (envelope-from ) for ; Sat, 11 Mar 2023 17:51:28 +0100 Received: from aspmx1.migadu.com ([2001:41d0:2:4a6f::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by mp10.migadu.com with LMTPS id MKMhFZCxDGRzZQAAG6o9tA (envelope-from ) for ; Sat, 11 Mar 2023 17:51:28 +0100 Received: from lists.gnu.org (lists.gnu.org [209.51.188.17]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by aspmx1.migadu.com (Postfix) with ESMTPS id 01CC015837 for ; Sat, 11 Mar 2023 17:51:27 +0100 (CET) Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1pb2Qy-0006Wt-OX; Sat, 11 Mar 2023 11:51:04 -0500 Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1pb2Qx-0006Va-25 for guix-patches@gnu.org; Sat, 11 Mar 2023 11:51:03 -0500 Received: from debbugs.gnu.org ([209.51.188.43]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1pb2Qw-0005of-Q5 for guix-patches@gnu.org; Sat, 11 Mar 2023 11:51:02 -0500 Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1pb2Qw-00020r-Ad for guix-patches@gnu.org; Sat, 11 Mar 2023 11:51:02 -0500 X-Loop: help-debbugs@gnu.org Subject: [bug#61765] custom toolchain blog post Resent-From: Mitchell Schmeisser Original-Sender: "Debbugs-submit" Resent-CC: guix-patches@gnu.org Resent-Date: Sat, 11 Mar 2023 16:51:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 61765 X-GNU-PR-Package: guix-patches X-GNU-PR-Keywords: moreinfo To: Ludovic =?UTF-8?Q?Court=C3=A8s?= Cc: 61765@debbugs.gnu.org Received: via spool by 61765-submit@debbugs.gnu.org id=B61765.16785534437713 (code B ref 61765); Sat, 11 Mar 2023 16:51:02 +0000 Received: (at 61765) by debbugs.gnu.org; 11 Mar 2023 16:50:43 +0000 Received: from localhost ([127.0.0.1]:58543 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pb2Qc-00020J-Av for submit@debbugs.gnu.org; Sat, 11 Mar 2023 11:50:43 -0500 Received: from mx1.librem.one ([138.201.176.93]:40354) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pb2QZ-000206-Uf for 61765@debbugs.gnu.org; Sat, 11 Mar 2023 11:50:40 -0500 Received: from smtp.librem.one (unknown [192.241.214.14]) by mx1.librem.one (Postfix) with ESMTPS id 132B981E8D; Sat, 11 Mar 2023 08:50:32 -0800 (PST) Content-Type: multipart/alternative; boundary=Apple-Mail-C0B47D03-9E84-4226-8125-A6AD6DAB625D Content-Transfer-Encoding: 7bit Date: Sat, 11 Mar 2023 11:50:28 -0500 Message-Id: References: <87zg8jwkqc.fsf@gnu.org> In-Reply-To: <87zg8jwkqc.fsf@gnu.org> X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-BeenThere: guix-patches@gnu.org List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Reply-to: Mitchell Schmeisser X-ACL-Warn: , Mitchell Schmeisser via Guix-patches From: Mitchell Schmeisser via Guix-patches via Errors-To: guix-patches-bounces+larch=yhetil.org@gnu.org Sender: guix-patches-bounces+larch=yhetil.org@gnu.org X-Migadu-Country: US X-Migadu-Flow: FLOW_IN ARC-Authentication-Results: i=1; aspmx1.migadu.com; dkim=none; spf=pass (aspmx1.migadu.com: domain of "guix-patches-bounces+larch=yhetil.org@gnu.org" designates 209.51.188.17 as permitted sender) smtp.mailfrom="guix-patches-bounces+larch=yhetil.org@gnu.org"; dmarc=pass (policy=none) header.from=gnu.org ARC-Seal: i=1; s=key1; d=yhetil.org; t=1678553488; a=rsa-sha256; cv=none; b=lItF4SPMqRg7BQwLWjd7WhXuOqbUbNiLv6EdgFnG8ZxVOMUDQuipJSWS4743S7VCB8d9No 3X67h5rbNPgrllmNc8xP+fu59/LWScdatEr9V93WyigJw/nf8xsDH8sTnOJOyfytScppwJ z//DXCf1Sq8MV2iX1SGI4XO/DRnxxnx7MCbXvbya6kSjT+HgkFaMtJYuKd0+b/+weWWt/E VCnTbqnwuTeJSjosMM85yRsMlBB9C+2yGUxWHpc5LV0saYHufZLu/wmns/MwoZ2Ze7LrXa zfnEdIexEV7cCRqYCPIImvMenVos3twRK4/wc6yBmAnhDzoxz7z/g1oySFob/g== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=yhetil.org; s=key1; t=1678553488; h=from:from:sender:sender:reply-to:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:content-type:content-type: content-transfer-encoding:content-transfer-encoding:resent-cc: resent-from:resent-sender:resent-message-id:in-reply-to:in-reply-to: references:references:list-id:list-help:list-unsubscribe: list-subscribe:list-post; bh=xqz0+B7uV9LyCEh+HQdi+1oTCbyUjpg4hCivavoE3H0=; b=PpYIXSbLsDnPoyaS99MLUOWB0RncH5kIx2IZFRhIV0MfrfbOtA6Hk7+dhupL1ifbCod5FS pWaENIgKHM+ngqYewE8+SnKv+xFTmdoy31hpmesdinPXY0RfYq4NMS8jOlah8bbnsN8Hmr G/wWhxRGCt4/sXiT3o6hp547RAL5v4hGbxxQBM75340SVWTvoWsPevu9ANYumU1ZPGVsQy 3ELSYflqGObf+eKGb8u9QfTOXcFKmRcvcNcCSqyNNTNcSp314GIWoJ7hyQM9ST8OOhACd2 bn4ZlAGkLQ+KF9Z9bDfuvyu0Qra9wxcWo8NQ2YVl29qJCPwV7nUQJGjsOo+Hog== X-Migadu-Spam-Score: -1.70 X-Spam-Score: -1.70 X-Migadu-Queue-Id: 01CC015837 X-Migadu-Scanner: scn1.migadu.com Authentication-Results: aspmx1.migadu.com; dkim=none; spf=pass (aspmx1.migadu.com: domain of "guix-patches-bounces+larch=yhetil.org@gnu.org" designates 209.51.188.17 as permitted sender) smtp.mailfrom="guix-patches-bounces+larch=yhetil.org@gnu.org"; dmarc=pass (policy=none) header.from=gnu.org X-TUID: S9x6Qc2aEmvU --Apple-Mail-C0B47D03-9E84-4226-8125-A6AD6DAB625D Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi Ludo, >=20 > OK. To put it differently, a typical POSIX program won=E2=80=99t work on > Zephyr; programs have to target the Zephyr interfaces, right? This is mostly correct. I think a lot of my conceptual difficulties come fro= m the fact that west/zephyr try to tackle the issues of software deployment a= nd 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 t= hrough several thousands of lines of cmake. Every bit as complex as the kern= el kconfig but even more so since modules can be scattered across the file s= ystem. One of the selling points of zephyr is that your application is abstracted f= rom the hardware and can run on multiple boards without modification. Howeve= r to make this happen you need to do a lot of work on the application side.=20= Below you can see an example. You have to provide the proper kernel config f= or every target you want to support. https://github.com/zephyrproject-rtos/zephyr/tree/main/samples/net/mqtt_publ= isher Using guix there may be a more elegant solution to these problems but maybe n= ot. Thank you for all your feedback, Mitchell > On Mar 11, 2023, at 7:12 AM, Ludovic Court=C3=A8s wrote: >=20 > =EF=BB=BFHi Mitchel, >=20 > (Please keep the issue Cc=E2=80=99d.) >=20 > Apologies for the delay! >=20 > Mitchell Schmeisser skribis: >=20 >>> One thing that=E2=80=99s not clear to me: with this in place, can you do= =E2=80=9Cguix >>> build --target=3Darm-zephyr-eabi hello=E2=80=9D, for instance? If not, w= hat=E2=80=99s >>> missing to support it? >>=20 >> 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. >>=20 >> It's not that it's impossible to implement something like `guix build >> --target=3Darm-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. >=20 > OK. To put it differently, a typical POSIX program won=E2=80=99t work on > Zephyr; programs have to target the Zephyr interfaces, right? >=20 >> The way I envision the `--target/system` flags being used in this >> context is `guix build --target=3Darm-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. >=20 > Or rather: >=20 > guix build --target=3Darm-zephyr-eabi k64f-hello-world >=20 > ? >=20 >>> I wonder if it would be worth mentioning >>> too, and how >>> one would go about adding a module. WDYT? >>=20 >> 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. >>=20 >> There will be a part 3 (and possibly more) about how to practically use >> this stuff in a real project. >=20 > Woow. :-) >=20 >> =46rom 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 >>=20 >> website/blog/custom-toolchains-with-guix.md: New file >=20 > 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. >=20 > https://git.savannah.gnu.org/cgit/guix/guix-artwork.git/tree/website/draf= ts/custom-toolchains-with-guix.md >=20 > (BTW, I made slight modifications to some of the code snippets to! One > package was using (append (list =E2=80=A6) (package-native-inputs =E2=80=A6= )), which > really works =E2=80=9Cby chance=E2=80=9D I guess; you should use =E2=80=98= modify-inputs=E2=80=99 > instead.) >=20 > Let me know if anything=E2=80=99s amiss! >=20 > Thanks, > Ludo=E2=80=99. --Apple-Mail-C0B47D03-9E84-4226-8125-A6AD6DAB625D Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi Ludo,

OK.  To put it differently, a t= ypical POSIX program won=E2=80=99t work on
Zephyr; programs have to targe= t the Zephyr interfaces, right?
This is mostly c= orrect. I think a lot of my conceptual difficulties come from the fact that w= est/zephyr try to tackle the issues of software deployment and dependency ma= nagement 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 co= mponent composition but Zephyr tries to do all composition through several t= housands of lines of cmake. Every bit as complex as the kernel kconfig but e= ven more so since modules can be scattered across the file system.
One of the selling points of zephyr is that your application is abstracted f= rom the hardware and can run on multiple boards without modification. Howeve= r to make this happen you need to do a lot of work on the application side.&= nbsp;
Below you can see an example. You have to provide the proper= kernel config for every target you want to support.

Using g= uix there may be a more elegant solution to these problems but maybe not.

Thank you for all your feedba= ck,
Mitchell


On Mar 11, 2023, at 7:12 AM, Ludovic Cou= rt=C3=A8s <ludo@gnu.org> wrote:

=EF=BB=BFHi Mitchel,

(Please keep the issue Cc=E2=80=99d.)
<= br>Apologies for the delay!

Mitchell S= chmeisser <mitchellschmeisser@librem.one> skribis:

One thing t= hat=E2=80=99s not clear to me: with this in place, can you do =E2=80=9Cguix<= /span>
build --target=3Darm-zephyr-eabi hello=E2=80=9D, for insta= nce?  If not, what=E2=80=99s
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 targe= ting Zephyr
when they= are written. The application will include a `prj.conf` which
is analogous to a custom defconfig i= n the Linux kernel.
E= ither in this file, or somewhere in the CMakeLists.txt a `BOARD`
<= /blockquote>
variable is set to specify a spe= cific board definition.
These board definitions contain information about the architecture and
the CMake scripts thems= elves pick the toolchain.
<= span>
It's not that i= t's impossible to implement something like `guix build
--target=3Darm-zephyr-eabi k64f-hello-worl= d` 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 PO= SIX program won=E2=80=99t work on
Zephyr; programs have to t= arget the Zephyr interfaces, right?

The way I envision the `--target/system` flags being used= in this
context is `= guix build --target=3Darm-linux-gnueabihf k64f-hello-world`
which will still produce the correct f= irmware but will allow the
= firmware to be staged to another machine which will be responsible for=
the final deployment= over some transport.

Or rathe= r:

 guix build --target=3Darm-zephyr-= eabi k64f-hello-world

?

I wonder i= f it would be worth mentioning
<https://guix.gnu.org/ma= nual/en/html_node/Platforms.html> too, and how
one woul= d go about adding a  module.  WDYT?

I considered trying to add Zephyr platforms but I'm not su= re it's worth
the eff= ort.
In addition to t= he patch to the website I attached another post(in org)
which describes how I integrated this too= lchain into the Guix
= infrastructure to allow defining firmware packages.
<= blockquote type=3D"cite">Maybe there will be additional information in= there which can help you
<= span>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 r= eal project.

Woow.  :-)

=46rom 0920ec7d951= 354c94c3da277d58e54b587522622 Mon Sep 17 00:00:00 2001
From: Mitchell Schmeisser <mitchellschm= eisser@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 f= ile

I pushed it under the draf= ts directory for now, to leave others a bit
more time to com= ment before we publish.  I followed up with a commit
ed= iting things a bit, mostly fixing typographical issues,
spel= ling/capitalization, code formatting, and removing tabs.

 https://git.savannah.gnu.org/cgit/guix/guix-artwork.git= /tree/website/drafts/custom-toolchains-with-guix.md
<= br>(BTW, I made slight modifications to some of the code snippets to! &= nbsp;One
package was using (append (list =E2=80=A6) (package= -native-inputs =E2=80=A6)), which
really works =E2=80=9Cby c= hance=E2=80=9D I guess; you should use =E2=80=98modify-inputs=E2=80=99
instead.)

Let me know if anythin= g=E2=80=99s amiss!

Thanks,
= Ludo=E2=80=99.
= --Apple-Mail-C0B47D03-9E84-4226-8125-A6AD6DAB625D--