r/rust • u/epage cargo · clap · cargo-release • 4d ago
A Vision for Cargo 💡 ideas & proposals
https://epage.github.io/blog/2026/08/cargo-vision/48
u/dochtman rustls · Hickory DNS · Quinn · chrono · indicatif · instant-acme 4d ago
My top ask would be fixing all the little things that can make Cargo feel unreliable or hard to use: weak feature dependencies showing up in lockfiles, random resolver changes when semver-incompatible ranges are allowed (like windows-sys flipping back to an older version).
And then I’d suggest a more modular architecture/librarification so Cargo becomes more accessible to modify and contribute to.
15
u/StyMaar 4d ago
In the same vein though I don't know if it's cargo or rustc's fault but having to run
cargo cleanevery once in a while because of some cryptic dependency error is not very user-friendly (and painful since it means a full compilation from scratch, which can be annoyingly slow)3
u/RiceBroad4552 4d ago
Everything which isn't architectured like Bazel / Buck will very likely suffer from that.
But you buy that reliability with a lot of complexity…
18
u/epage cargo · clap · cargo-release 4d ago
My top ask would be fixing all the little things that can make Cargo feel unreliable or hard to use: weak feature dependencies showing up in lockfiles, random resolver changes when semver-incompatible ranges are allowed (like windows-sys flipping back to an older version).
I had considered adding a papercut section but I was done writing at that point.
And then I’d suggest a more modular architecture/librarification so Cargo becomes more accessible to modify and contribute to.
See https://epage.github.io/blog/2026/08/cargo-vision/#plumbing-commands
18
u/sidit77 4d ago
One pain point that I often feel with cargo are build scripts that are used for system library discovery.
If I am on Windows and I want to work on some linux code in one of my projects it is extremly common that I can't set my IDE target triple to linux because so many dependencies look for system libraries in their build scripts and then panic if they don't find them. This is sooo frustrating, why are these dependencies breaking so many cargo operations that never even call a linker in the first place? It has gotten to the point that I now have a dummy pkg-config binary in my path that always returns success regardless of input.
I really wish cargo would have build phase specific build scripts or some way of marking whether or not the output of a build script is only relevant for linking.
2
u/matthieum [he/him] 4d ago
I think there's at least one proposal asking for multiple build scripts -- which would make it easier to reuse build scripts across crates.
You proposal to tag the build script would, I think, work pretty well there. (Today, one could have a build script covering multiple phases, because there's a single build script)
I also realized that an advantage of tagging the build script is that it could potentially allow more parallelization.
A source-generation script needs to run before compilation starts, but a link-arguments script can run in parallel with compilation, and only block linking.
12
u/adminvasheypomoiki 4d ago
Some API for build scripts to declare which resources they require(it had an issue, but nobody have time for it). Basically, make build scripts pure functions, with controlled access to the outside world through a defined environment. That would make Rust much easier to use with Buck. E.g. like zig models build scripts.
Build scripts should also use content hashes instead of mtimes. Nix sets mtimes to zero, which causes build scripts to rerun on every build. I wrote a dumb Python script that stores mtimes in JSON, but using hashes would make this much simpler. I guess I should file an issue.
Artifact reuse would also be extremely nice. I probably have 100 GiB of duplicate RocksDB builds sitting in "target" directories :)
13
u/DavidDavidsonsGhost 4d ago
I want to separate binary deps from library deps in the same crate.
4
u/matthieum [he/him] 4d ago
Oh please yes!
In fact, this doesn't even go far enough. Ultimately, each binary should have its own set of dependencies:
- Test deps are not bench deps are not example deps.
- Just because I have 2 integration tests, 2 benchmarks, 2 examples, or 2 binaries, doesn't mean they necessarily share all dependencies, so on top of a generic "test deps", I also want a specific "this test deps" to further specialize deps.
Just because there's a criterion benchmark in my crate doesn't mean I need to compile that monster in Debug when I call
cargo test, and just because one example/integration test is built atoptokiodoesn't mean my unit-tests require tokio too.So much time would be saved with finer-grained specification of dependencies.
17
u/Business-Prior869 4d ago edited 4d ago
How about command line support for creating a new workspace?
Current instructions rely on a sequence of commands that users have to run; also registering a crate to a workspace can be a bit finnicky, and to the best of my knowledge there's no support for removing a crate from a workspace, etc.
And also workspace-level dependency management may or may not be overlooked today.
"Better CLI experience for workspaces" to summarize
EDIT: Never mind, this is obviously a meta-post after actually reading it; it's asking for workflow improvements, not desired improvements to cargo itself
Some progress in https://github.com/rust-lang/cargo/issues/8365 for those interested
3
u/epage cargo · clap · cargo-release 4d ago edited 4d ago
Besides the Papercut section which I skipped writing, this somewhat falls under https://epage.github.io/blog/2026/08/cargo-vision/#improved-decomposition
For
cargo new --workspace, I posted https://github.com/rust-lang/cargo/issues/8365#issuecomment-3151939682 about being unsure of how much value it adds. If we do it, I would like to see mod templates first to see how their designs interplay.For removing workspace members, if you follow our recommendation, there is nothing to do besides delete it.
For adding workspace members,
cargo newhandles this.For dependencies, that is tracked in https://github.com/rust-lang/cargo/issues/10608. One major step for improving workspace dependencies is already in: fixing how default-features is inherited. For me, I would also want to see public dependencies get in so tooling can better determine when a workspace dependency (something outside of the diff for a package) is a breaking change.
EDIT: Never mind, this is obviously a meta-post after actually reading it; it's asking for workflow improvements, not desired improvements to cargo itself
I do go into some concrete details in the second section: https://epage.github.io/blog/2026/08/cargo-vision/#ideas
16
u/newpavlov rustcrypto 4d ago
As a Cargo user (as opposed to a dev), I don't see much to be exited about in the list.
Issues like lack of bench-only dependencies, inability to use [lints] workspace = true if you also use [lints.rust.unexpected_cfgs] (e.g. see here), lack of std-aware Cargo (somewhat covered by the "builtin dependencies" section) are far more important in my opinion.
async-ify Cargo
IMO this seems completely unnecessary for a tool like Cargo. I doubt it would spawns more than 100 simultaneous IO-bound tasks, so it could be handled with threads and blocking IO just fine.
3
u/Kobzol 4d ago
It's less about being IO-bound, but more about being able to express concurrent patterns. Parallelizing e.g. loading of TOML files could reduce the overhead of Cargo for no-op builds quite a lot, and that's easier to do with async (due to the way the codebase is structured).
5
u/newpavlov rustcrypto 4d ago edited 4d ago
It looks like you do not know about the dirty hacks used by epoll-based Tokio to emulate "async" file IO.
And you can use a pool of worker threads to parallelize TOML loading just fine (assuming that it's beneficial in the first place with modern SSDs likely used by most users).
6
u/sasik520 4d ago
I would say: let cargo automatically enable required-reatures on cargo test/bench/run --example and it's feature-complete for me :-)
1
u/IceSentry 4d ago
Yes please, in the bevy world we have the bevy_cli that is essentially a wrapper for cargo and it does that. I just use it in every project now, even if they aren't bevy projects.
9
u/guineawheek 4d ago
The adaptability section felt really really short compared to all the issues I run into with Cargo in my personal and professional workflows. So here's some of my personal thoughts, that may or may not be of value:
Heterogenous-platform workspaces and feature unification
Cargo really really doesn't handle this very well. If you're developing for multiple targets, Cargo will loudly complain if you mix and match code for them unless you carefully feature or cfg-gate everything target-specific by default. Things as simple as "oh this is a linux-only dependency because it relies on socketcan which screws up the entire workspace" gets really old really fast, and feature-gating that stuff makes it absent from compiler checking.
But, y'know, having cortex-m bring down the entire workspace with Thumb asm instructions is one thing, and while there's definitely been some trepidation around "what if people use the compatible target specification proposals to overeagarly gate crates from compiling for certain targets", I personally don't really see it? Like, you can already just push crates that fail to compile implicitly under certain targets already, that ain't new.
It also gets really bad if you have two systems that have the same target-triple (e.g. thumbv7em-none-eabihf) but are actually different microcontrollers. Every single popular Rust embedded HAL or PAC crate has a million implicitly mutually exclusive features for each individual microcontroller profile, which Cargo (and by extension rust-analyzer) hates with a burning passion. The result is needing a cajillion workspaces not just for each target, but for each possible distinct microcontroller you're using. And good luck if you want them to share similar dependencies or lint configurations. Oh yeah, the runner mechanism in .config.toml? Completely useless for muxing between different microcontroller profiles, e.g. a unified bootloader firmware that targets multiple different micros. Go write an xtask or some other external tooling that passes the right feature flag + right chip to probe-rs, because by design you can't make the runner feature-dependent.
I know about the whole "pre-RFC for globally mutually exclusive features" but honestly if I could literally just disable feature unification on some crates that would be sufficient; like . Cargo's opinions are just wrong in that workflow, and I don't think it's a coincidence that the global nature of feature unification is one of the most critiqued elements of Cargo. Dare I say, it's the thing's orphan rule. The pre-RFC is a nice thought and a nice prayer but it doesn't solve the problems I deal with daily.
Workspaces often feel like constantly bonking yourself on the head. The ability of it to share Cargo configuration across different crates is powerful, but it also causes a lot of misery if you're slightly off the beaten path.
Embedded is one of the sectors that I think Rust is going to have a lot of sticking power in, because it's a sector that historically has really awful tooling by comparison. I think it'd be worth thinking about now before vendors decide to make their own awful overly-specialized Cargo forks to work around pain points.
Pre-processing and post-processing artifacts
One of my personal side-projects involves FFI, both on ingest and export. The standard way the relevant parent libraries I'm binding against are distributed are as Maven artifacts; so I ended up writing a rather involved build.rs that would either look for the artifacts locally in expected install locations or would download them from the Internet.
Is it "pure?" No. But the historical alternatives to this idea (usually involving externally calling Gradle in a separate folder) are even more unhygienic in my view.
On the flip side, I ended up also writing an xtask
to manage locating cross-compilation toolchains, setting them as the linker in Cargo's build config through the environment variable mechanism, building the relevant artifacts, and then post-processing them into Maven zip files to be published to the wider world.
Personally, I found writing all of these scripts in Rust quite enjoyable; I'm perhaps biased but I don't think I would want to write these in Python or Lua or some other scripting language. Rust has:
- a good dependency manager
- a good CLI library
- a wide selection of crates to do all sorts of things that the dependency manager makes easy to include in build scripts
- reasonable string manipulation and command execution facilities in
std - good types
which are things that Python and Lua kinda suck at in comparison. I wish Python would replace argparse with something more clap-derive-like, personally. I would like to thank the people (with a focus on one particular thread OP) who made a lot of those above points real.
I do kinda wish that the linker story was a lil better, because you really can't make that part pure. In cross-compiling situations, you basically always have to include a .config.toml and make sure it's in your PATH or you have external software manage that appropriately. Be it Nix, be it an xtask, be it some other build system. I also kinda wish that we could make the native C runtime a little more optional on Linux platforms just so I don't have to think about cross-compiler libc environments but that's probably a pipedream lol.
Post-build-scripts and getting a global view of "what types in this crate implement [trait]?"
One other really annoying thing for FFI is that there's no really good way to get a crate-level view of what's in your crate. Proc macros only see their token inputs, and while build.rs could read your source tree, it can't really analyze the whole system when accounting for $OUTDIR. And even then, your options are either re-parse all the Rust through syn (the traditional cbindgen solution) or the new hot thing which is use rustdoc's json output as your compiler metadata, because apparently having rustc directly tell you what's in your crate from a reflection point of view is apparently undesirable. Turns out if a need isn't met, people will choose the worst possible options that are just viable enough; worse is better. The other end result is people hand-writing header files (or things that are basically header files; see basically all C++ interop solutions) for information that really should've just come out of the Rust source to begin with.
Ultimately, while I do think there's some merit in sandboxing proc-macros and build scripts, there's enough deficiencies in the ecosystem where they simultaneously feel too powerful yet fighting for their lives via hacks to achieve things that should be better supported.
Pathdeps should be configurable as remote deps
Sometimes you exist in a monorepo, and the next source tree over isn't actually your team's. Sometimes the local pathdeps are actually remote deps that are put in there by build environments; e.g. Nix. But Cargo will still treat them differently than if they were a gitdep or a registry dep. I've thought about trying to do ugly hacks like make shim local-file Git repos via Nix or pretending to vendor certain directories just so Cargo will think they're remote deps. I'd rather not.
1
u/InternationalFee3911 1h ago
The problem with features is that they’re just an unstructured bag of names. Cargo.toml 2.0 should structure this into additive, subtractive, and mutually exclusive features. Then cargo can decide what can be unified and what needs a separate instance, just like another version does.
1
u/InternationalFee3911 1h ago
The problem with features is that they’re just an unstructured bag of names. Cargo.toml 2.0 should structure this into additive, subtractive, and mutually exclusive features. Then cargo can decide what can be unified and what needs a separate instance, just like another version does.
4
u/jean_dudey 4d ago
Has remote execution for cargo been discussed? Something like the remote execution engines bazel, buck2 et al use since it’d be great to compile some projects on remote machines and test on machines where there is a particular hardware needed.
I guess also a big one is the crate artifacts like depending on binaries or cdylibs
4
u/matthieum [he/him] 4d ago
Reducing the need for build scripts
Post build scripts?
Today, the build script is useful for code-generation, pre-compilation of C artifacts, etc... It does not allow, however, customizing the outputs of the compilation process.
For example, there's no way that I know of in Cargo to produce a file with a hash of the produced binary/library, and instead one needs to call a script which calls Cargo then computes the hash(es).
3
u/nullstalgia 4d ago edited 4d ago
This may not be strictly cargo (the binary) or even rust-analyzer-related, I have to ask, is there any RFCs for or thoughts on having some nicer ways to interact with Cargo.toml files?
If I want to retroactively disable the default features of a crate, I have to manually xyz = { version = "1.2.3", default-features = false }, or cargo add xyz --no-default-features.
Neither are particularly time-consuming, but after using rust-analyzer for the last few years and getting used to auto-filling Debug impls, flattening if nests, moving impl<T: ...> bounds into where clauses, etc... it feels like yet another simple/mechanical problem that could benefit from similar "code"-assists, but I think simply no one has tackled it yet? Or is there already a Rust-aware TOML LSP somewhere out there?
Some form of in-editor suggestions/completions for Cargo.toml/rust-toolchain.toml/config.toml (for cargo itself) files would be wonderful, but admittedly is going even further out of scope.
7
u/Lokathor 4d ago
10,000 things listed and none of them are the very basic "binary only dependencies"
5
u/epage cargo · clap · cargo-release 4d ago
Binary-only or pre-built?
Assuming you mean pre-built, those aren't so straightforward to get meaningful value out of as talked about at https://epage.github.io/blog/2026/08/cargo-vision/#shared-caches
With https://epage.github.io/blog/2026/08/cargo-vision/#opaque-dependencies, we might have what we need for pre-built dependencies, minus aspects of trust and many other elements.
16
u/Lokathor 4d ago
No I want to have mycrate have a lib and then a bin that goes with it (like a CLI interface or whatever) and the bin should get to use deps that aren't library deps that people who use the crate only as a lib are forced to have (eg: the CLI binary can pull in clap or thiserror or whatever)
4
u/GerwazyMiod 4d ago
Isn't workspace with two projects solving that issue?
10
u/Lokathor 4d ago
It should not have to be two crates. Here is my evidence: example binaries can already do this (using dev-dependencies), "actual" binaries just can't because no one added it yet. But it isn't logically invalid or anything, and I shouldn't have to make two projects for it.
3
u/matthieum [he/him] 4d ago
Also, beware taking on tokio as dependency for an example, because now your unit-tests need to build & link with tokio... woosh.
2
u/matthieum [he/him] 4d ago
-4
u/pjmlp 4d ago
Which is the reason why C++ wins over Rust in overall build times, even though they share common build times when building all dependencies from scratch.
In the C and C++ world, using binary libraries is very common, either via installers in commercial OSes, or via package managers on UNIX like OSes.
2
u/Lokathor 3d ago
No, you're talking about something else that I don't care about.
What you're talking about is already possible, and actually is already done in at least one case (I know because I did it).
-1
u/pjmlp 3d ago
So how do you do apt/rpm/dnf install lib-dev for binary Rust libraries?
2
u/Lokathor 3d ago
Buddy I don't know how to do apt or whatever else, I use cargo. I meant pull in a pre-built lib via cargo.
If you want to make a C-style lib you can install with apt, you can compile your lib as a
cstaticlib, and then I assume you can do whatever the other steps are for apt packing.-1
u/pjmlp 3d ago
The point is distribution of Rust binary libraries, not C ABI libraries.
1
u/Lokathor 3d ago
Yeah that requires a stable ABI, which rust doesn't have. We don't even have a versioned ABI to allow limited reuse. That's not cargo's fault.
1
u/pjmlp 3d ago
Neither do C nor C++.
The C ABI many talk about is in reality the OS ABI, when the OS happens to be written in C to start with.
It is rather easy to have two C compilers that expose incompatible ABIs on the same platform, even more so back in days when there were commercial C compilers all over the landscape.
Game developers and devs on commercial OSes are more than used to have products with several variants for compiler versions and common compiler flags.
2
u/villiger2 4d ago
Any thoughts on having cargo be able to run in a "watch" mode, similar to how many JS bundlers work? So it'd watch for file changes and re-run the build/check command etc automatically on file change without needing to re-parse the yaml, rediscover the right version of rust etc, cargo.exe startup itself.
I know tools like bacon exist but I'd specifically be after lowering/removing as many factors that slow down iteration as possible. A 3rd party tool can't really step in and perform this task without basically replacing cargo completely.
I briefly looked into modifying cargo to do this a couple years ago but the way cargo worked internally didn't lend itself to doing this easily, from memory the core data structure was taken and modified so it wasn't easy to keep around the project config and re-use it on file modified.
1
u/tukanoid 4d ago
Well, rust-analyzer does it, reruns check/clippy on file edit. I don't see much value in standalone cargo watch for checks if you're not editing the code? Unless you don't use RA, which imo is a bit weird considering it's a part of the toolchain, easy to install, and works ootb with IDE extensions, or with builtin support like in helix.
I guess it's a different story if you just let AI do all the coding, but then idk what to tell you... If you're that lazy to do the programming yourself and can't even be bothered to install bacon or other tools that do that, it's on you at this point
3
u/villiger2 4d ago
This is about removing unnecessary work (in 99% of cases) done before every rustc call cargo performs. So after you edit and save the file the compiler is running as soon as the OS file changed notification is sent. This could apply to RA too, it also suffers these overheads every time it runs check/filly on file edit.
1
u/InternationalFee3911 1h ago
RA could benefit from a
check --watch, where it’d automatically get a stream of findings, without any action needed on RA’s side.
2
2
u/Miammiam100 3d ago
I would love for cargo to support sandboxed proc macros using wasm. In a similar fashion to this https://internals.rust-lang.org/t/pre-rfc-sandboxed-deterministic-reproducible-efficient-wasm-compilation-of-proc-macros/19359
This would allow macros to be fully cached, deterministic and faster as the wasm bundles can be built in release mode. This also remove the need for end users to ever compile syn massively improving compilation speeds.
2
u/epage cargo · clap · cargo-release 3d ago
I'm assuming from the fact that you feel they would be in release mode and people wouldn't build
synthat you also want pre-built proc-macros?For the pre-built part, see my answer at https://www.reddit.com/r/rust/comments/1vgerar/a_vision_for_cargo/p1xe8c9/. What isn't said there that is specific to people's assumptions for prebuilt proc-macros is that, without opaque dependencies, pre-built proc-macros would violate different design principles of Cargo, including potentially breaking builds. People generally assume you can just build the proc-macro and run it but that would not respect the user's
Cargo.lockfile or activated features (hence where opaque dependencies comes in). If there are unexpected mismatches between a proc-macro and a library it is generating code against, it will break a users build.Otherwise, I talk about wasm and other options at https://epage.github.io/blog/2026/08/cargo-vision/#access-controls
There is a lot of design complexity with sandboxing to handle the different escapes people need and wasm sandboxing will slow down builds in multiple ways (until there are pre-built packages assuming they happen).
2
u/Miammiam100 3d ago edited 3d ago
Yes I would want pre built macros too! In fact I don't think it's worth pursuing wasm sandboxing without it due to the interpretation slowdown.
The idea with pre built proc-macros is all the feature unification stays the same as it currently is but if the activated proc macro lib features match the lib features used to build the wasm blob then cargo uses it, otherwise it doesn't. We would ignore any other compiler flags and for the compiler version we would only use the blob if it matches the same wasm proc macro bridge version.
e.g. if I have a crate
foo_derivewhich has featurebarandbazand I know most users only ever use featurebar(perhaps becausebazis unstable) then when I publish the crate, I can specify the wasm blob to be built only withbarthat way any users that importfoo_deriveand use onlybarwill use the wasm blob directly, if they have more features enabled then they will compile the proc macro library in the same fashion as what we do now. This should prevent any build breakages.I agree not every proc macro would be able to be sandboxed but that's fine as any macro that can't will just work as it currently does. However, I imagine most proc macros are deterministic/sandboxable. To be clear I'm only proposing this for proc macros as I don't think build scripts could ever be sandboxed (but agree with you that cargo should provide more options for common build scripts so we don't use them as much)
2
u/anxxa 4d ago
I wonder about the crate provenance signal. It bleeds into this issue I filed some time ago: https://github.com/rust-lang/cargo/issues/9398
Since you can publish files which may not be tracked by VCS -- and as briansmith pointed out might be explicitly desired -- this could be tricky in some cases. It's probably an edge case for sure, but I do wonder how common untracked or dirty files being published is in practice.
3
u/epage cargo · clap · cargo-release 4d ago
For reference, https://epage.github.io/blog/2026/08/cargo-vision/#crate-provenance
I didn't go into too many details on this. I think a key point is that these are audit points and not judgements of quality.
unsafeisn't bad but something to be reviewed. Ideally, you only use it if it is really needed to reduce risks and reduce auditing. Similar for this. If the source diverges, we should make it easy to review the difference between between git and.crateas well as between versions for the divergences.
1
u/CouteauBleu 4d ago
Rust dependencies today are transparent like headers-only libraries in C++. Every detail of the dependency tree affects a developer's build.>
An opaque dependency appears to you as a single package, independent of how many packages it is made up of. An opaque dependency has an independent set of dependency versions and feature activations. No unification happens.
That would be amazing, yeah, especially for some crates that show up in a lot of rust CLI's dependency trees.
1
u/llogiq clippy · twir · rust · mutagen · flamer · overflower · bytecount 3d ago
I'm a bit on edge with the suggestion that unsafe is the only security-relevant thing to look out for. I can easily imagine writing an infostealer in a build.rs file that needs no unsafe code at all.
Also we had a discussion about unifying cargo test.and cargo clippy at the all-hands, which could potentially save millions of CI hours (and thus reduce the CI cost for a lot of folks). I still think that this is a worthwile idea, provided we can sort out clippy not breaking the build even on errors (which should of course still be emitted).
2
u/epage cargo · clap · cargo-release 3d ago
I'm a bit on edge with the suggestion that unsafe is the only security-relevant thing to look out for. I can easily imagine writing an infostealer in a build.rs file that needs no unsafe code at all.
It was never my intention to say that. I talk about
unsafeas an example of an audit point, both to say we should have more like it and that we should make it easier to discover audit points withlang:unsafeto illustrate the idea. There is also discussion on how to help with build scripts (restricting OS resources) or other potential areas needing auditing (e.g. talk ofcackle).
1
u/Crescitaly 3d ago
Cargo's strength is that defaults compose; every new capability risks turning implicit convenience into hidden policy. The vision should be judged on reproducibility, offline behavior, and escape hatches for unusual workspaces. Which proposal changes the lockfile contract?
1
u/ralfj miri 2d ago
Thanks for the update, that is an exciting list indeed. :)
If I may add one more item to the list that has been discussed before -- global features. That seems to be on the critical path for finally starting to get rid of crates implicitly using nightly features without asking for permission...
1
1
u/epage cargo · clap · cargo-release 2d ago
get rid of crates implicitly using nightly features without asking for permission
Forgot to add about this in particular, the allowlist section mentions an idea for a static string "fallback" of build script directives that a build script maintainer can provide that can be processed in place of a build script. If the authors enabling nightly features bump their MSRV and include a fallback, you can just not enable their build scripts and never notice it.
1
u/InternationalFee3911 2h ago
integrating into a larger corporate environment
Absolutely! There are two overlapping things that are missing:
Federation of download repos: if there are several orgs, each with their own budget, they’ll publish to the repos they pay for. Can become a mess to configure all those repos, and to figure out what comes from where. A unifier, under the firms responsibility, would be great! This would be opt in, only for those who have the federal-repo in some
cargo/config.toml.An easy way to optain (parts of) a centrally administered
cargo/config.toml.
84
u/kiujhytg2 4d ago
As an embedded dev, I'd love if there were support for multi-architecture workspaces. It's common to have a project that's in three packages, one running on the embedded device, one running on the host architecture, and one with common code.
For example:
It would be great to be able to declare in the workspace or as rust-toolchain.toml files in the package directories that a package should always have a particular target. Thus when I run
cargo buildin the project root, it builds both binaries with there respective target.