Hacker News Reader

Comment by polpo | Hacker News Reader

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.

View on HN

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

[2] https://pigweed.dev/docs/blog/01-kudzu.html

[3] https://pigweed.dev/seed/0111-build-systems.html

[4] https://pigweed.dev/docs/mission.html

Is this a Google project? I didn't know google source code hosting was still a thing.

Yep, it's a Google project. We've also got a GitHub mirror: https://github.com/google/pigweed

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

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

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

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})

Very much appreciate the details

I'm off for the night but will follow up here next week

We can also continue discussion on the Discord https://discord.gg/M9NSeTA

Closing the loop:

* I'm forwarding your feedback to the team.

* I will make sure we follow through on the plan to include CMake examples in our WIP "examples" repo [1] and will make sure pigweed.dev links to those examples consistently.

* Our new module docs guidelines require every module to have a quickstart section that includes how to set up the module in every build system we support, including CMake [2]. That should help a bit but based on your experience it sounds like there's a lot more we need to cover in these quickstart sections.

(I don't want to overcommit on behalf of other teammates but as docs lead these things are safely within my realm to change.)

[1] https://pigweed.dev/seed/0122-code-samples.html#examples-rep...

[2] https://pigweed.dev/pw_function/#get-started

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.

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.

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.

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.

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.

Nothing can be as bad as having to write autoconf/automake.

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.

Reply on news.ycombinator.com