4 ms·

> I doubt that cargo covers all those scenarios as well * cross compilation: cargo --target=... , you can also cross compile and then run tests for a different

> I doubt that cargo covers all those scenarios as well * cross compilation: cargo --target=... , you can also cross compile and then run tests for a different target easily (by running them with qemu or in a VM, or via USB in an actual phone or embedded device, etc.) * formating: cargo fmt * linters: cargo clippy * valgrind: cargo valgrind * sanitizers: RUSTFLAGS="-Zsanitizer=..." cargo test builds and runs tests with sanitizers * code coverage: cargo tarpaulin and that's just for the basics. I've seen teams spending weeks on CMake and only being able to set a subset of these up. There are many others, like dumping the inline assembly of a function in a big project (cargo asm function_name), dependency management, etc. As an ex CMake developer and CMake user for >10 years, I'm happy to work on Rust full time just for the benefit of not having to use CMake ever again.

Arch-TK 5y ago
>I've seen teams spending weeks on CMake and only being able to set a subset of these up. Aside from the fact that formatting has nothing to do with building (or development for that matter) that sounds like either a CMake issue or an issue I described in another comment where a problem is identified, a solution is hypothesized, and an attempt is made to implement the solution, all without ever considering if either a: the problem identified is a problem or the right problem, b: the solution hypothesized is the only or best solution and c: if the implementation is implementing the solution or not. >As an ex CMake developer and CMake user for >10 years, I'm happy to work on Rust full time just for the benefit of not having to use CMake ever again. There are other options than CMake.