Stream: general

Topic: Rust Without Cargo?

Sean Klein (Apr 16 2020 at 19:34, on Zulip):

Are there recommended "best practices" or standards for developing Rust in a Cargo-less environment?

I'm familiar with a handful of projects that enable this -- Bazel's rules_rust/cargo_raze approach, Fuchsia's approach (using GN and avoiding Cargo altogether) but I was kinda curious about these techniques from people more embedded within the rust community

Sean Klein (Apr 16 2020 at 19:39, on Zulip):

I think I'm particularly interested in environments where multiple programming languages are used together -- which I suppose would be the first motivation for "hey, it's a pain to build my C++/Go/Rust libraries/binaries from Cargo alone"

Sean Klein (Apr 16 2020 at 19:42, on Zulip):

(also, maybe the answer is "you should still use Cargo in those cases! You should just invoke it by another build system, or whatever!" - just curious to hear what has / hasn't worked well in this space)

Josh Triplett (Apr 16 2020 at 21:29, on Zulip):

That's definitely the small-scale recommendation, yes.

Josh Triplett (Apr 16 2020 at 21:30, on Zulip):

Doing without Cargo has less to do with mixing languages, and more to do with "we have an existing all-encompassing build system of doom, and everything must fit into that".

Lokathor (Apr 16 2020 at 21:42, on Zulip):

If Rust isn't the primary project language you can set cargo to produce a staticlib and then have the larger build process grab that and make use of it, for example.

Vadim Petrochenkov (Apr 16 2020 at 22:04, on Zulip):

So, I wanted to start a rant about Cargo being an opaque non-divisible non-cooperative blob inside of a dependency graph of any actual build system, including off the shelf CMake, not only "all-encompassing build systems of doom", causing build performance issues once the project size grows.
However, I've just found that Cargo can actually inherit the outer build system's jobserver now, so it's not so uncooperative anymore, just non-divisible and opaque.

Josh Triplett (Apr 16 2020 at 22:09, on Zulip):

I personally don't feel like Cargo is that much more indivisible than rustc, or than the use of LTO.

Josh Triplett (Apr 16 2020 at 22:09, on Zulip):

I don't think it's necessarily a great assumption that all programs should be able to compile like C, where each source file becomes one object, for instance.

Josh Triplett (Apr 16 2020 at 22:09, on Zulip):

@Lokathor Agreed, that seems like the easiest solution.

simulacrum (Apr 16 2020 at 22:15, on Zulip):

Hm, AFAIK the "inherit a jobserver" has been true for ... years now? Basically since we started doing it

Vadim Petrochenkov (Apr 17 2020 at 07:23, on Zulip):

simulacrum said:

Hm, AFAIK the "inherit a jobserver" has been true for ... years now? Basically since we started doing it

Perhaps the "indivisibility" was resolved as well?
IIRC, if CMake run multiple instances of Cargo in parallel, they started competing with each other for various locks, both global and in the workspace build directory, serializing the build anyway.

(Assume I have a workspace with multiple packages producing staticlibs, cdylibs and executables for consumption by the outer CMake. If each package is made a separate node (target) in CMake build graph, then CMake can build the packages when it's necessary for the larger build, possibly in parallel.)

simulacrum (Apr 17 2020 at 10:42, on Zulip):

No, I think that hasn't been resolved. Cargo still expects to roughly be the only cargo running (and enforces that). Crater currently creates N target directories as a workaround.

Last update: Jun 05 2020 at 20:55UTC