5 ms·

Setting up CMake to support dozen hardware architectures and operating systems (and cross compiling), have targets for basic stuff like code formating, linters,

Setting up CMake to support dozen hardware architectures and operating systems (and cross compiling), have targets for basic stuff like code formating, linters, running tests with/without valgrind, sanitizers, etc. generating code coverage instrumentation, etc. used to be a huge time sync. For projects using CMake, I'd argue that one of the main features of Rust is that it enables to spend all that time into adding actual functionality to your programs.

pjmlp 5y ago
I doubt that cargo covers all those scenarios as well, given how Google and others have gone implementing their own replacements to cover exactly such kind of workflows.
- maxwell86 5y ago
  > 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.
deleted 5y ago
[deleted]

pjmlp 5y ago

I doubt that cargo covers all those scenarios as well, given how Google and others have gone implementing their own replacements to cover exactly such kind of workflows.

maxwell86 5y ago
> 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.

deleted 5y ago

[deleted]