Allow usage in a CMake-based build

[maelp]

Hi (cross-linking from espressif/rust-esp32-example#34)

thanks so much for your work on embedded rust, and in particular on ESP chips :)

We're a company using ESP on our hardware, and we'd love to move our codebase to Rust. Because that move will be incremental, we'd like to compile our C/C++ codebase and switch some modules to Rust incrementally. For this, it seems more natural to use a "CMake-based" build that would compile our Rust modules as a library, and link our code to it. And of course, we'd love to use esp-idf-svc :)

For now, we saw https://github.com/ivmarkov/rust-esp32-std-hello which uses esp-idf-svc, but uses a "cargo-first" build which seems less natural for us.

Would it be possible to allow building esp-idf-svc using a CMake build so that it can be included in a CMake project like for instance https://github.com/espressif/rust-esp32-example ?

[ivmarkov]

@igrr, @georgik - to make the CMake-first build compatible with esp-idf-sys (and thus with esp-idf-svc and friends), we really only need to define three additional environment variables and pass them down to Cargo here. (The names of the env variables I've given below are completely arbitrary):

• CARGO_CMAKE_BUILD_INCLUDES - this should be a delimited list of all include directories of all ESP-IDF components. If that makes it easier, having additional - user-components - on that list will not be a problem, I think. Btw, I tried with get_target_property(CARGO_CMAKE_BUILD_INCLUDES ${COMPONENT_TARGET} COMPONENT_INCLUDES) as well as a few other variations, but none of these worked.
• CARGO_CMAKE_BUILD_SDKCONFIG - this should be the full path to the sdkconfig file used during the build. A less ergonomic alternative would be for this environment variable to directly contain all CONFIG_* options - somehow delimited - from the sdkconfig
• CARGO_CMAKE_BUILD_COMPILER - the full path to the compiler (as in GCC) used during the build. We need this so as to derive a proper sysroot for the Bindgen utility.

Any help (in terms of CMake syntax) as to from where to get the content of these three variables would be greatly appreciated!

[ivmarkov]

@georgik Can you help with ^^^? I have the (minimal) changes to the esp-idf-sys crate ready, but unless we figure out the above problem, there is no way to test these...

[maelp]

That would be really nice if we could do it, we'd love to be able to start hacking on Rust with esp-idf-svc :)

[ivmarkov]

• Necessary changes (6 lines) to a CMake project embedding rust lib here.
• Patch to esp-idf-sys to support CMake-first projects here.

[ivmarkov]

@georgik As per my comment in the Matrix channel - strictly speaking - you can use esp-idf-sys and esp-idf-svc without STD. None of these crates imply STD or "enable" STD. (It is another topic why you would want to use those in a no_std environment, of course and in fact why you would want to mark your Rust code as no_std when it will be linked against the ESP-IDF libc library anyway.)

All these crates give you, is (a) unsafe, autogenerated Rust bindings to the ESP-ID C APIs (= esp-idf-sys) and (b) safe, manually written Rust bindings on top of the unsafe ones (= esp-idf-svc). (And a way to auto-build and link-with the ESP-IDF, but that's only for cargo-first builds.)

So in fact I would argue that the above environment variables (CARGO_CMAKE_*) should be passed always and regardless whether the concrete crate is built with or without STD.

Side topic: this code seems a bit strange. The decision (whether your crate is having a "std" feature enabled or not - and note that this is different from e.g. building the std library as part of your crate build) should not be taken based on the chip type.

Overall, I think there is still some confusion around the whole STD topic. For a reason of course - the topic is a bit intricate and the presence of two "std-related" notions (the no_std notion and the notion of whether you want to build - as part of your crate build - either the std library or the core library) does not make it easier. Perhaps we should discuss during the next meeting.

[igrr]

Side topic: this code seems a bit strange.

IIRC this might be a leftover (?) from the time when we couldn't build std on rv32imc due to missing atomics.