4 ms·

I don't disagree, I find cargo insufficient for projects of any meaningful complexity (it doesn't even support post build steps...). But it's really good at one

• rhn_mk1 5y ago
  > But it's really good at one thing: compiling crates. Unless you're using "compiling" as strictly compiling, and not "building", then I don't agree either. It falls flat on its face if you want a build time choice between dependency versions, for example. And build.rs means that Cargo washes its hands from compiling parts of crates that are not written in Rust, so it's arguably not good at compiling (of anything but pure Rust). The way Cargo is integrating several concerns also makes it hard to create better build systems for Rust, because they would have to pull in the same kitchen sink in order to support Cargo.toml. So that's being bad at letting others compile as a bonus. EDIT: Actually, that wouldn't be a problem if Cargo the decent package manager didn't mandate Cargo the awful build system.
  • hctaw 5y ago
    As much as I agree that Rust needs a better story for builds and interacting with other languages, it sounds like you have a misunderstanding over what Cargo primarily does and what crates are. A crate is a single compilation unit of Rust. Cargo is a tool for compiling crates and pulling in other crates that it references. build.rs is a half measure to include foreign symbols in compilation artifacts like static/shared libraries and executables. I'd go so far as to advise against using it for anything but specifying linker flags. I don't think I've ever had a use case for specifying dependency versions at build time. That seems insane, and I do insane things in cmake with regularity. There's a reason versions are pinned to a config file committed to repos in almost every contemporary language. fwiw, Cargo is a crate itself and you can use it as a library. You can even compile it with C language bindings to call through FFI in other build systems if you felt like it. The lang tools team has done a great job with keeping the scope of Cargo manageable and putting in the ground work to make better tooling around it. For complex Rust builds, check out cargo-make. It does most of what you'd need in a predominantly Rust codebase. For polyglot environments, cmake with custom targets is the least bad way I've found to do it - and it's not hard to do that by shelling out to Cargo.
    • rhn_mk1 5y ago
      A crate may be a compilation unit, but it's irrelevant. Within the Rust space, a crate is a library. something like 95% of crates are using Cargo, and Cargo requires that dependencies are also using Cargo. Today it's impossible to ditch Cargo, and publish your crate with e.g. Bazel as the build system. There's no misunderstanding that what Cargo does it build Cargo crates. The problem is that it doesn't allow for sanely built (so not using Cargo) crates. > specifying dependency versions at build time Packaging for different distributions, where different versions of a dependency are provided, is quite a common thing, and has justifications beyond technical reasons.