Now add some dependencies, some required, some optional, for all platforms, or some specific to some platforms.

Then add configuration options for conditional compilation, and a build system to define them properly.

Then use the configuration options of your dependencies in your build system.

Finally, repeat this process for every project and make sure you use the same syntax/api for your build system so you don't have to relearn everything everytime.

cc main.c is as easy as it gets when you rewrite everything from scratch.

cargo is as easy as it gets when you want an ecosystem.

Add a closed source dependency in Rust and see how far cargo takes you.

I assume the closed source dependency is distributed as a .a/.so/.dll file, then you can use bindgen[0].

Still, yes it's a bit more complicated. But can we not pretend that the non-existent toolchain in C/C++ is easier in 99% of use cases?

[0] - https://medium.com/dwelo-r-d/using-c-libraries-in-rust-13961...

No, I want a closed source Rust dependency. Otherwise it's going through a C API and I lose all of the benefits of using Rust.

Once you solve this problem, C++ & CMake are of similar complexity for C++ dependencies.

Otherwise to compare C++ toolchains, if it's distributed as a .a file, just adding -l/path/to/libclosed.a works for C++, can't get more simple than that. Or one line in the CMake file with basically the same thing.

A .rlib file then, that you can then add with:

  RUSTFLAGS="--extern closedlib=path/to/libclosedlib.rlib"

Yes, but only for tiny tools or toys.

Most software have dependencies that should be managed, linked in, figure the header file path of etc. Most software consists of several files which you don't want to re-build every time you change just 1 file (unless you change compiler flags etc.). It's a very tiny step from your example until the C or C++ toolchain becomes far from easy.