[robot_no_421]

I cannot overemphasize how enjoyable it is to work with cargo when I'm coding in Rust; I think it's one of the major reasons why Rust took off. As complicated as Rust is, it's a breeze to not only build projects but also add existing projects as dependencies.

[pornel]

Most of my Rust projects, even large and complex ones, don't have any build script at all. That made me realize how much time and energy I used to waste on maintaining build scripts.

[jenadine]

I beg to disagree. Sure, when you want to have a small project that only uses crates.io d'EPS, Cargo is simple and gets the job done. But once you want to do something a bit more complex, (like getting a dependency of something not written in rust, or picking features based on some system configuration), you quickly get to the limitations and there is not much you can do.

Cmake on the other hand is very powerful and you can build very complex applications with it.

[robot_no_421]

Ok, but do you actually enjoy using CMake, or do you accept how horribly complex it is because it lets you do some esoteric thing you want to do?

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.

[vvanders]

> like getting a dependency of something not written in rust, or picking features based on some system configuration

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.

[jenadine]

> I've found that things like this are pretty straightforward with a build.rs

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

[vvanders]

> build.rs can't change the feature set.

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.

[1] https://crates.io/crates/pkg-config