Usage without CMake

[crystalthoughts]

Hi, I notice in the docs you mention that CMake is integral to the build process of this library.

However I might like to port it to something like Zig in the future which has an integrated build system.

Is it impossible to use without CMake? Could you give me some pointers as to how I might try to use this without CMake/with a different build system?

Of course I can scan through the CMake files and see what it’s doing but maybe something to be aware of.

[lurch]

Something similar has been asked several times before. See e.g. #1360 #897 #703

[crystalthoughts]

Yes, but very little information was conveyed :) I'm asking for any relevant advice so I can try it myself

[crystalthoughts]

To give some ideas: A high level overview of what CMake is handling in the case of this project, how it is helping make this build process simpler? Is there anything specific to the baremetal pipeline to be aware of? For example the sections relating to ELF2UF2.

What's stopping me from directly including dependencies / building directly without CMake.

The docs are quite sparse on these things.

[peterharperuk]

Sorry, but I think it's unlikely you'll get much help with this on here

[crystalthoughts]

Could you explain why? Even this response is frustratingly vague! Do you mean because it's a set of questions too common to build systems in general? Or because there's not enough will or time to help?

[peterharperuk]

Time. At some point a decision was made to use cmake. I doubt there's any reason why another tool couldn't be used and I doubt there's any reason why you couldn't build without cmake. But without actually doing it, which I would imagine would take a long time that we don't have, it's hard to be sure what obstacles would get in the way. No doubt you'd end up solving all the same problems. Personally I would prefer to spend my time on more productive tasks. Hope that makes sense.

[crystalthoughts]

Thanks for your insight

[lurch]

If you haven't done so already, I guess you'll want to have a thorough look at https://datasheets.raspberrypi.com/pico/raspberry-pi-pico-c-sdk.pdf especially Chapter 2.

[crystalthoughts]

Thanks, I didn't spot there was more info in the pdf :) The overview there is useful. I'll probably start by directly porting tiny sections of the SDK to my target language and seeing if I can get minimal example running.

[lurch]

https://github.com/raspberrypi/pico-sdk/blob/master/README.md#documentation :wink:

[crystalthoughts]

Yes I did see that page ;)

[lurch]

I'll probably start by directly porting tiny sections of the SDK to my target language

If you're trying to "port" the SDK to an entirely different programming language, you might find https://github.com/rp-rs/rp-hal to be a useful inspiration? :man_shrugging:

[crystalthoughts]

Thanks I'll take a look. Perhaps I can compare how they do all the ELF2UF2 type stuff which I'm in the dark about.

I'm going to start with some Odin tests which is closer to C than Rust is. Progressively adapting the syntax of functions in this repo, as I need them, should get me most of the way. And it's very easy to include a C static library if needed.

When Zig is more stable the integrated build system will be very appealing.

As some background motivation - I think experienced C/C++ coders underestimate the sheer learning curve and complexity of the whole tooling ecosystem due to familiarity. I'm not part of some big team so it's not how I like to work

[daniel-j]

On the topic of alternative languages for the Pico SDK, I've wrapped the SDK in Nim and integrated CMake. https://github.com/daniel-j/picostdlib

Nim compiles to C so this integration is really easy. The list of compiled C files just gets added as target sources in CMake. This way it's easy to keep up to date when Pico SDK gets updated, and Cyw43 chip on Pico W just works as expected. The integration is deeper than that with some generated .cmake and files Nim can parse.

I have not used Zig but found this, seems similar to what Rust does (e.g. not using the SDK): https://github.com/ZigEmbeddedGroup/raspberrypi-rp2040

It might be possible to do something similar with Zig as I did with Nim if you can compile a static binary and link it from CMake side? Since Zig doesn't generate C code currently. I tried it with Nim, it worked but the resulting binary was slightly larger.

[lurch]

It might be worth moving this conversation to https://forums.raspberrypi.com/ and closing this issue?

[crystalthoughts]

To me it's a relevant issue that someone might want to look into one day , considering ease of adoption/binding by users of other languages. But close away if you have to. (Edit: notice how the Rust and Zig project did not choose to bind the great work already done here)

There was also a comment from kilograham in an other issue suggesting it was on a rough roadmap to consider decoupling the build system a bit more, but sounds like it won't happen any time soon.

[lurch]

I'm afraid we're all very busy, and providing support for 3rd-party build systems (when CMake works just fine for 99% of users) is something unlikely to get any attention soon.

[crystalthoughts]

Ok , point taken! Note that I originally only asked for a high level overview. By the time we've finished debating this maybe it could have been written and I would have been more helpful to the project. (I take the previous point about unknown unknowns but most of the 120 or so CMake defs seem to be a couple of lines) But maybe I'm sounding difficult, not intended. Thanks for the work put in thus far. (●'◡'●)