5 ms·

Cargo doesn't recompile all crates on each iteration, you are missing something definitely. It only recompiles changed code. Or if rustc/cargo version has been

Cargo doesn't recompile all crates on each iteration, you are missing something definitely. It only recompiles changed code. Or if rustc/cargo version has been changed. "a bit of catch up" is one thing, not mentioning most powerful IDE plugin is another.

pjmlp 10y ago
This is not what I see, I imagine you are talking inside one single project, while I mean across all Rust applications I might have available. 1 - Get Project A 2 - Crate X gets compiled as one of the dependencies 3 - Get Project B 4 - Crate X gets compiled again as one of the dependencies I usually see this when compiling all the VSCode related projects during new Rust releases. Could the reason be that Crate X on Project A and Project B isn't the same version? Where are the binary rlib visible to all cargo projects stored? I could only find text versions zipped together. I haven't checked this deeply yet, just seeing "Compiling crate X" multiple times isn't fun.
- EugeneOZ 10y ago
  All projects are independent and binaries are stored in "target" folder. It's a good thing. Even libs nominally same versions can have different source code and dependencies (because of "replace" or vendoring).
  - pjmlp 10y ago
    No, it is not a good thing. It is a waste of my development time that I could use for productive work. On other AOT compiled languages that I use at work, I can reuse binaries across projects, including the languages Rust intends to replace. It is a hard sell, if using Rust means having to spend more time compiling than even with C++ (specially now that modules are finally coming, at least for us with VC++).
    - EugeneOZ 10y ago
      For me is a good thing, because, as I explained, version number is not a guarantee.
      - pjmlp 10y ago
        So, than cargo needs to be improved so that there is a set of dependency values (name, version, rustc version, etc) that can guarantee the uniqueness of a binary library. To me it seems FOSS undervalues the value of binary libraries in the enterprise, or how they get used in many corporations or companies selling components. Rust improved safety is a good thing™, but not at the expense of continuously seeing the same libraries being compiled over and over, vs reusing binary artifacts across projects.
        EugeneOZ 10y ago
        Cargo needs to be improved, here I agree :)
    - p0nce 10y ago
      dub (D build tool) support both of these locations. I can attest stuff gets reused.
  - icebraining 10y ago
    It doesn't have to use the version, it could hash the source, like ccache.
- steveklabnik 10y ago
  We don't do any of this kind of caching because flags can be different per-project. There's an open bug on it; it's not impossible, we just haven't used it yet.
  - pjmlp 10y ago
    Same applies to any language that compiles to native code or has support for conditional compilation. Even with MIR, Rust will never compile faster than C or even C++ if dependencies on binary libraries aren't supported. Right now I can compile my C++ projects on Windows, and .NET Native ones, faster than when updating Rustfmt, racer and Rustsym, after each new Rust release. VS2017 will bring the new linker, and the ongoing MS work for C++ modules (now a TS). Rust won't win the hearts of C++ developers if it doesn't allow for binary dependencies, and doesn't compile faster.
    - deleted 10y ago
      [deleted]

pjmlp 10y ago

This is not what I see, I imagine you are talking inside one single project, while I mean across all Rust applications I might have available. 1 - Get Project A 2 - Crate X gets compiled as one of the dependencies 3 - Get Project B 4 - Crate X gets compiled again as one of the dependencies I usually see this when compiling all the VSCode related projects during new Rust releases. Could the reason be that Crate X on Project A and Project B isn't the same version? Where are the binary rlib visible to all cargo projects stored? I could only find text versions zipped together. I haven't checked this deeply yet, just seeing "Compiling crate X" multiple times isn't fun.

EugeneOZ 10y ago
All projects are independent and binaries are stored in "target" folder. It's a good thing. Even libs nominally same versions can have different source code and dependencies (because of "replace" or vendoring).
- pjmlp 10y ago
  No, it is not a good thing. It is a waste of my development time that I could use for productive work. On other AOT compiled languages that I use at work, I can reuse binaries across projects, including the languages Rust intends to replace. It is a hard sell, if using Rust means having to spend more time compiling than even with C++ (specially now that modules are finally coming, at least for us with VC++).
  - EugeneOZ 10y ago
    For me is a good thing, because, as I explained, version number is not a guarantee.
    - pjmlp 10y ago
      So, than cargo needs to be improved so that there is a set of dependency values (name, version, rustc version, etc) that can guarantee the uniqueness of a binary library. To me it seems FOSS undervalues the value of binary libraries in the enterprise, or how they get used in many corporations or companies selling components. Rust improved safety is a good thing™, but not at the expense of continuously seeing the same libraries being compiled over and over, vs reusing binary artifacts across projects.
      - EugeneOZ 10y ago
        Cargo needs to be improved, here I agree :)
  - p0nce 10y ago
    dub (D build tool) support both of these locations. I can attest stuff gets reused.
- icebraining 10y ago
  It doesn't have to use the version, it could hash the source, like ccache.
steveklabnik 10y ago
We don't do any of this kind of caching because flags can be different per-project. There's an open bug on it; it's not impossible, we just haven't used it yet.
- pjmlp 10y ago
  Same applies to any language that compiles to native code or has support for conditional compilation. Even with MIR, Rust will never compile faster than C or even C++ if dependencies on binary libraries aren't supported. Right now I can compile my C++ projects on Windows, and .NET Native ones, faster than when updating Rustfmt, racer and Rustsym, after each new Rust release. VS2017 will bring the new linker, and the ongoing MS work for C++ modules (now a TS). Rust won't win the hearts of C++ developers if it doesn't allow for binary dependencies, and doesn't compile faster.
  - deleted 10y ago
    [deleted]