[isopede]

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

[kaycebasques]

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

[isopede]

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

[kaycebasques]

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

[kaycebasques]

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