Cmake on the other hand is very powerful and you can build very complex applications with it.
Every tool has limitations, sure. But I think you're disagreeing about something I didn't even say. I didn't say cargo can replace CMake. I said that cargo is really a pleasure to use when it's the tool you need. If you had the choice to either build with CMake or cargo, I promise you that you'd rather use cargo if possible.
Building most C/C++ projects seems pretty miserable no matter what build process you're using. CMake seems like a huge mental burden in itself. Cargo just does its job and gets out of the way.
I've found that things like this are pretty straightforward with a build.rs and you aren't context switching between a configuration language and your target language since build.rs is just a Rust program that outputs configuration values via println.
> ... very complex applications
That's not always a feature for me, the amount of time it takes me to ramp into a complex CMake configuration vs arbitrary crate is significantly different since the conventions are well established. If you spend any time cross-compiling things the Rust experience(I.E. first-class triple support, cc crate) is miles above anything CMake provides.
- build.rs can't change the feature set.
- what they usually do to bring dependency is vendor the C files within the crates, but when it comes to configuring to use an installed library and passing the right linker flags, this becomes really tricky.
Can you be more specific here? You can totally do that based on OS, environment vars or even direct feature flags in the Cargo.toml. I've got a number of projects that do this and let downstream consumers decide what features they want. At the end of the day it's just a Rust program that runs ahead of the build and can do anything that you would be able to do in a normal command line program.
> ... but when it comes to configuring to use an installed library and passing the right linker flags, this becomes really tricky.
pkg-config[1] does all of that including returning linker flags. I can't think of a single case where I wasn't able to integrate with an existing library.
I'm not saying there are zero issues(I.E. passing some linker flags as a dependent crate gets annoying) but my experience having used C++ across a number of platforms(Win32, Linux, proprietary systems) before CMake existed and after it started getting wider adoption is that CMake has a significantly higher hurdle and is just harder to get things working correctly, especially under cross-compilation configurations.