4 ms·

I'm going to push back on the comment in the article about the build system being overkill. While "tiny" is a relative term, not all projects built for the RP20

by polpo 3y ago

I'm going to push back on the comment in the article about the build system being overkill. While "tiny" is a relative term, not all projects built for the RP2040 are tiny – my PicoGUS project relies on several external libraries and being able to bring them in via CMake is pretty great. Also while the Pico itself is fixed hardware, the SDK targets many other boards built on the RP2040. The Raspberry Pi team definitely have things architected for future versions of the microcontroller as well as on-host testing of the SDK.

kaycebasques 3y ago
We (the Pigweed team) are big fans of the RP2040/Pico ecosystem. We built out a pretty deep GN-based build system for it; check out the source code [1] for our Gameboy-style electronic badge Kudzu [2] for an example. We're also prototyping Bazel integrations (since Bazel is our primary build system [3] going forward). Pigweed might be overkill [4] for small hobby projects but we think it might be pretty nice for big/complex projects built on top of RP2040. I know you said you're happy with CMake (and we too think CMake is great; Pigweed also has CMake support), I'm just excited that there are other build system options and figured others might be interested to hear that other options exist. [1] https://pigweed.googlesource.com/pigweed/kudzu/+/refs/heads/main https://pigweed.googlesource.com/pigweed/kudzu/+/refs/heads/... [2] https://pigweed.dev/docs/blog/01-kudzu.html https://pigweed.dev/docs/blog/01-kudzu.html [3] https://pigweed.dev/seed/0111-build-systems.html https://pigweed.dev/seed/0111-build-systems.html [4] https://pigweed.dev/docs/mission.html https://pigweed.dev/docs/mission.html
- doublepg23 3y ago
  Is this a Google project? I didn't know google source code hosting was still a thing.
  - kaycebasques 3y ago
    Yep, it's a Google project. We've also got a GitHub mirror: https://github.com/google/pigweed https://github.com/google/pigweed
- isopede 3y ago
  I tried to evaluate pigweed a little bit by importing just a single module (pw_result) into my existing CMake-based MCU project. I guess you guys technically do have support, but it seemed unnecessarily difficult to pull in. Just pull the source code in, and link against pw_result right? Nope. I ended up having to spend a few hours working out what the heck facades are, various handlers for I/O, implement my own crash handlers, all the while having to poke through/model existing handlers that had "DO NOT USE IN PRODUCTION" written all over it. I did end up getting it working, but it was clear that GN/Bazel is the blessed build system and CMake is just an afterthought. In contrast, I pulled in expected-lite [1] with a single line of CMake's FetchContent, #include'd the header, and it just worked. [1] https://github.com/martinmoene/expected-lite https://github.com/martinmoene/expected-lite
  - kaycebasques 3y ago
    Yes I should amend [1] to say "Pigweed has some CMake support". We're aware it's way too hard to do simple CMake stuff. Sorry if I / we oversold it. It's on our radar to do a lot better with CMake docs, examples, etc. and your comment might be just what was needed to light a fire under our butts We wrote an explainer on facades, did you see that / did it help? I will comb through the docs and make sure any module that uses facades links to the explainer https://pigweed.dev/docs/facades.html https://pigweed.dev/docs/facades.html Thank you for trying it out and for the feedback, and sorry again for the pain For my notes, did you just try it out right now or was this in the past? [1] Just checked, I no longer have edit access to my previous comment
    - isopede 3y ago
      I tried it a few months ago, back in November. I looked through what I did and in the end, to bring in pw_result, I had to define a failure handler, pull in three separate cmake files for various definitions, define an ASSERT action (because a result type requires an ASSERT fail, apparently?), and set a backend and a handler for pw_assert. At some point I remember it complaining left and right about not having the right I/O methods for printing, etc. I just wanted to try the result type, and for some reason I needed to define I/O mechanisms for my platform. Is this the correct procedure? I have no idea, because the cmake documentation had (has?) _zero_ examples. If they existed, I couldn't find them. I eventually got it to compile with the following snippet, but I can hardly believe that this is the "intended" way to do it. FetchContent_Populate(pigweed) include(${pigweed_SOURCE_DIR}/pw_build/pigweed.cmake) include(${pigweed_SOURCE_DIR}/pw_assert/backend.cmake) include(${pigweed_SOURCE_DIR}/pw_assert_basic/backend.cmake) add_compile_definitions(PW_ASSERT_BASIC_ACTION=PW_ASSERT_BASIC_ACTION_LOOP) pw_set_backend(pw_assert.check pw_assert_basic.check_backend) pw_set_backend(pw_assert.assert pw_assert_basic.basic_handler) add_subdirectory(${pigweed_SOURCE_DIR} ${pigweed_SOURCE_DIR})
colinsane 3y ago
i don't think the build system is overkill. but it's the same phenomenon as docker: if you grew up with it then it's easy to use and solves all your problems easily and you've probably forgotten that it was ever difficult. but if not, then it's this arcane monolith that you've no hope of actually understanding. this applies to every general-purpose build system.
- TillE 3y ago
  It would be really difficult to find an experienced C++ developer these days who isn't comfortable with the basics of CMake, and that's all the Pico SDK demands from you. If you're simply a hobbyist grudgingly writing C/C++ then sure, something like Arduino would be a lot more appealing.
  - colinsane 3y ago
    i've been writing C++ half my life, C a couple years less, stopped using them daily 4 years ago, but i've shipped enough projects with them to be "experienced". exactly one of those projects use CMake (an open source Qt app that's had a couple million downloads), and the infra for that was pretty finalized by the time i got there. if "comfortable with the basics" means "add a new .c file to the list of stuff to compile", sure, easy. if it includes "detecting the presence of some optional dependency and then conditionally compiling+linking a .so in response" then not at all. more importantly though, a large number of cmake directives i cannot guess their effects except by consulting the manual. there's a lot of build systems out there. and a lot of technologies tend to come in pairs: a Qt C++ program is likely to use CMake, a GTK C/C++ program is likely to use meson, an SDL C/C++ program is likely to use make. not that there's no variance, but it's weirdly easy to specialize more narrowly than you think.
guenthert 3y ago
I think the discontent stems from "all this complexity to generate programs for a FIXED hardware with a fixed set of features", which I have some sympathy for. I do wonder however, whether the Pi Foundation wasn't looking ahead here, expecting more MCUs, with different features, to come after the RP2040.
127 3y ago
CMake is pretty great, in comparison to the older build tools for C and C++. But in comparison to any modern system (in other languages), it absolutely sucks.
- pjc50 3y ago
  Nothing can be as bad as having to write autoconf/automake.
CyberDildonics 3y ago
C can compile at 50 MB/s on one core. If there are mandatory source dependencies, they can all be stuffed into a single file with no problem.

by polpo 3y ago

kaycebasques 3y ago

We (the Pigweed team) are big fans of the RP2040/Pico ecosystem. We built out a pretty deep GN-based build system for it; check out the source code [1] for our Gameboy-style electronic badge Kudzu [2] for an example. We're also prototyping Bazel integrations (since Bazel is our primary build system [3] going forward). Pigweed might be overkill [4] for small hobby projects but we think it might be pretty nice for big/complex projects built on top of RP2040. I know you said you're happy with CMake (and we too think CMake is great; Pigweed also has CMake support), I'm just excited that there are other build system options and figured others might be interested to hear that other options exist. [1] https://pigweed.googlesource.com/pigweed/kudzu/+/refs/heads/main https://pigweed.googlesource.com/pigweed/kudzu/+/refs/heads/... [2] https://pigweed.dev/docs/blog/01-kudzu.html https://pigweed.dev/docs/blog/01-kudzu.html [3] https://pigweed.dev/seed/0111-build-systems.html https://pigweed.dev/seed/0111-build-systems.html [4] https://pigweed.dev/docs/mission.html https://pigweed.dev/docs/mission.html

doublepg23 3y ago
Is this a Google project? I didn't know google source code hosting was still a thing.
- kaycebasques 3y ago
  Yep, it's a Google project. We've also got a GitHub mirror: https://github.com/google/pigweed https://github.com/google/pigweed
isopede 3y ago
I tried to evaluate pigweed a little bit by importing just a single module (pw_result) into my existing CMake-based MCU project. I guess you guys technically do have support, but it seemed unnecessarily difficult to pull in. Just pull the source code in, and link against pw_result right? Nope. I ended up having to spend a few hours working out what the heck facades are, various handlers for I/O, implement my own crash handlers, all the while having to poke through/model existing handlers that had "DO NOT USE IN PRODUCTION" written all over it. I did end up getting it working, but it was clear that GN/Bazel is the blessed build system and CMake is just an afterthought. In contrast, I pulled in expected-lite [1] with a single line of CMake's FetchContent, #include'd the header, and it just worked. [1] https://github.com/martinmoene/expected-lite https://github.com/martinmoene/expected-lite
- kaycebasques 3y ago
  Yes I should amend [1] to say "Pigweed has some CMake support". We're aware it's way too hard to do simple CMake stuff. Sorry if I / we oversold it. It's on our radar to do a lot better with CMake docs, examples, etc. and your comment might be just what was needed to light a fire under our butts We wrote an explainer on facades, did you see that / did it help? I will comb through the docs and make sure any module that uses facades links to the explainer https://pigweed.dev/docs/facades.html https://pigweed.dev/docs/facades.html Thank you for trying it out and for the feedback, and sorry again for the pain For my notes, did you just try it out right now or was this in the past? [1] Just checked, I no longer have edit access to my previous comment
  - isopede 3y ago
    I tried it a few months ago, back in November. I looked through what I did and in the end, to bring in pw_result, I had to define a failure handler, pull in three separate cmake files for various definitions, define an ASSERT action (because a result type requires an ASSERT fail, apparently?), and set a backend and a handler for pw_assert. At some point I remember it complaining left and right about not having the right I/O methods for printing, etc. I just wanted to try the result type, and for some reason I needed to define I/O mechanisms for my platform. Is this the correct procedure? I have no idea, because the cmake documentation had (has?) _zero_ examples. If they existed, I couldn't find them. I eventually got it to compile with the following snippet, but I can hardly believe that this is the "intended" way to do it. FetchContent_Populate(pigweed) include(${pigweed_SOURCE_DIR}/pw_build/pigweed.cmake) include(${pigweed_SOURCE_DIR}/pw_assert/backend.cmake) include(${pigweed_SOURCE_DIR}/pw_assert_basic/backend.cmake) add_compile_definitions(PW_ASSERT_BASIC_ACTION=PW_ASSERT_BASIC_ACTION_LOOP) pw_set_backend(pw_assert.check pw_assert_basic.check_backend) pw_set_backend(pw_assert.assert pw_assert_basic.basic_handler) add_subdirectory(${pigweed_SOURCE_DIR} ${pigweed_SOURCE_DIR})

colinsane 3y ago

i don't think the build system is overkill. but it's the same phenomenon as docker: if you grew up with it then it's easy to use and solves all your problems easily and you've probably forgotten that it was ever difficult. but if not, then it's this arcane monolith that you've no hope of actually understanding. this applies to every general-purpose build system.

TillE 3y ago
It would be really difficult to find an experienced C++ developer these days who isn't comfortable with the basics of CMake, and that's all the Pico SDK demands from you. If you're simply a hobbyist grudgingly writing C/C++ then sure, something like Arduino would be a lot more appealing.
- colinsane 3y ago
  i've been writing C++ half my life, C a couple years less, stopped using them daily 4 years ago, but i've shipped enough projects with them to be "experienced". exactly one of those projects use CMake (an open source Qt app that's had a couple million downloads), and the infra for that was pretty finalized by the time i got there. if "comfortable with the basics" means "add a new .c file to the list of stuff to compile", sure, easy. if it includes "detecting the presence of some optional dependency and then conditionally compiling+linking a .so in response" then not at all. more importantly though, a large number of cmake directives i cannot guess their effects except by consulting the manual. there's a lot of build systems out there. and a lot of technologies tend to come in pairs: a Qt C++ program is likely to use CMake, a GTK C/C++ program is likely to use meson, an SDL C/C++ program is likely to use make. not that there's no variance, but it's weirdly easy to specialize more narrowly than you think.

guenthert 3y ago

I think the discontent stems from "all this complexity to generate programs for a FIXED hardware with a fixed set of features", which I have some sympathy for. I do wonder however, whether the Pi Foundation wasn't looking ahead here, expecting more MCUs, with different features, to come after the RP2040.

127 3y ago

CMake is pretty great, in comparison to the older build tools for C and C++. But in comparison to any modern system (in other languages), it absolutely sucks.

pjc50 3y ago
Nothing can be as bad as having to write autoconf/automake.

CyberDildonics 3y ago

C can compile at 50 MB/s on one core. If there are mandatory source dependencies, they can all be stuffed into a single file with no problem.