4 ms·

cargo is pretty straightforward for 95% of the cases, inconvenient for 3% of the cases, too limited for 1% of the cases, and extremely frustrating for the remai

cargo is pretty straightforward for 95% of the cases, inconvenient for 3% of the cases, too limited for 1% of the cases, and extremely frustrating for the remaining cases. I pulled the percentages out of thin air, but this is my experience. If your use case is straightforward, it's a breeze. Otherwise, welcome to some level of hell.

maxbond 4y ago
What does that 1% look like?
- SAI_Peregrinus 4y ago
  I'm not them, but usually stuff around FFI. Technically you can do whatever you need via build.rs, but imperative languages like Rust aren't really good for complex dependency resolution the way declarative languages like CMake and Bazel and Nix are. So as your dependency graph gets more complex (turns from a tree into a directed acyclic graph to a directed cyclic graph) Cargo loses the ability to sequence the operations properly without destroying your sanity. Dedicated build languages tend to be easier to use for these cases (though still not easy).
  - maxbond 4y ago
    Gotcha, interesting. Maybe there's a missing DAG library where you could define your build steps as functions and then express the dependencies &c in a neighboring TOML or YAML file, and it solves your DAG and executes the right functions in the right order. Sprinkle some rayon on there to parallelize tasks that are independent.
    - SAI_Peregrinus 4y ago
      The usual way to do that is just to use a more general build system to call Cargo (or to call rustc directly) and whatever other language(s) compilers you need. Cargo is a Rust-specific build system, it's not really designed to build other language's code easily (and doing so isn't a priority).
      - glandium 4y ago
        > it's not really designed to build other language's code easily That's quite funny to read, when the most low level crates rely on the cc crate to build C code (dependent of cc with the most downloads is backtrace, used by libstd, following that, openssl-sys, ring, libz-sys, you'll see those close to everywhere). But I see what you mean.
        SAI_Peregrinus 4y ago
        I guess the clearer way to state my point is that possibility and convenience are different things. `build.rs` scripts are Turing complete, and you can make syscalls, so you can call arbitrary other build systems. The difference in difficulty varies from language to language: C usually has few dependencies (because dependency management is fragmented and thus difficult) and so is often straightforward to compile, but other languages aren't always as easy. With a tangled mess of FFI dependencies Cargo stops being the best tool for the job.
  - bfrog 4y ago
    I’m not sure I agree that cmake is declarative.. look at complex builds with it and it looks a lot more like a badly designed scripting language with global state everywhere
    - SAI_Peregrinus 4y ago
      CMake can be used in a declarative fashion. So-called "Modern CMake" is declarative except for the "find" scripts which try to find the paths to various libraries on the user's system (since C has a dozen competing standards on where to put them).
      - bfrog 4y ago
        Would love to see a pedantic modern cmake example of you know if one
- glandium 4y ago
  Here's one tiny example: Want to link a static library that is also built from rust code? Yeah, you can make that work somehow by spawning another cargo from build.rs. Oh, you wanted to do that in a workspace? Ah no sorry, cargo is going to dead lock.
  - maxbond 4y ago
    The locking is super frustrating, I have cargo & rust-analyzer wrestle for it all the time, and my hacky solution for it so engrained that I just forgot it even happens until you mentioned.
    - glandium 4y ago
      Corollary of my example: when some hacky things rely on cargo to work (like some crate that does magic by using the output of cargo metadata (that actually exists, IIRC, or if not exactly that, something along those lines)), you better hope that the crate using those hacky things doesn't end up in your dependencies when you're using a workspace.

maxbond 4y ago

What does that 1% look like?

SAI_Peregrinus 4y ago
I'm not them, but usually stuff around FFI. Technically you can do whatever you need via build.rs, but imperative languages like Rust aren't really good for complex dependency resolution the way declarative languages like CMake and Bazel and Nix are. So as your dependency graph gets more complex (turns from a tree into a directed acyclic graph to a directed cyclic graph) Cargo loses the ability to sequence the operations properly without destroying your sanity. Dedicated build languages tend to be easier to use for these cases (though still not easy).
- maxbond 4y ago
  Gotcha, interesting. Maybe there's a missing DAG library where you could define your build steps as functions and then express the dependencies &c in a neighboring TOML or YAML file, and it solves your DAG and executes the right functions in the right order. Sprinkle some rayon on there to parallelize tasks that are independent.
  - SAI_Peregrinus 4y ago
    The usual way to do that is just to use a more general build system to call Cargo (or to call rustc directly) and whatever other language(s) compilers you need. Cargo is a Rust-specific build system, it's not really designed to build other language's code easily (and doing so isn't a priority).
    - glandium 4y ago
      > it's not really designed to build other language's code easily That's quite funny to read, when the most low level crates rely on the cc crate to build C code (dependent of cc with the most downloads is backtrace, used by libstd, following that, openssl-sys, ring, libz-sys, you'll see those close to everywhere). But I see what you mean.
      - SAI_Peregrinus 4y ago
        I guess the clearer way to state my point is that possibility and convenience are different things. `build.rs` scripts are Turing complete, and you can make syscalls, so you can call arbitrary other build systems. The difference in difficulty varies from language to language: C usually has few dependencies (because dependency management is fragmented and thus difficult) and so is often straightforward to compile, but other languages aren't always as easy. With a tangled mess of FFI dependencies Cargo stops being the best tool for the job.
- bfrog 4y ago
  I’m not sure I agree that cmake is declarative.. look at complex builds with it and it looks a lot more like a badly designed scripting language with global state everywhere
  - SAI_Peregrinus 4y ago
    CMake can be used in a declarative fashion. So-called "Modern CMake" is declarative except for the "find" scripts which try to find the paths to various libraries on the user's system (since C has a dozen competing standards on where to put them).
    - bfrog 4y ago
      Would love to see a pedantic modern cmake example of you know if one
glandium 4y ago
Here's one tiny example: Want to link a static library that is also built from rust code? Yeah, you can make that work somehow by spawning another cargo from build.rs. Oh, you wanted to do that in a workspace? Ah no sorry, cargo is going to dead lock.
- maxbond 4y ago
  The locking is super frustrating, I have cargo & rust-analyzer wrestle for it all the time, and my hacky solution for it so engrained that I just forgot it even happens until you mentioned.
  - glandium 4y ago
    Corollary of my example: when some hacky things rely on cargo to work (like some crate that does magic by using the output of cargo metadata (that actually exists, IIRC, or if not exactly that, something along those lines)), you better hope that the crate using those hacky things doesn't end up in your dependencies when you're using a workspace.