-
Notifications
You must be signed in to change notification settings - Fork 2.4k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
cargo workspace made easier #13219
Comments
Possible duplicate of #7285. I would create a cosmic-epoch issue instead. Cargo already seems to be able to handle duplicate dependencies: https://doc.rust-lang.org/cargo/reference/features.html#feature-resolver-version-2 |
i tried now with cargo, and stable. then with nightly, but interrupted it early:
and the cargo target is huge:
same software, same iced. written many times. that does not make any sense. i would understand 2 times, one for stable, one for nightly. |
The issue is that the project is not set up to use a workspace. It's just a repo with multiple git submodules. To be a workspace it would have to have a Cargo.toml in the parent directory with |
Step back a bit without looked at the proposed solution, this issue is looking for a way toshare build cache without explicitly creating a workspace. We have If there is a reason you are unable to create a workspace (maybe nested workspace issue #5042?), please share :) |
CARGO_TARGET_DIR is good enough. workspace is an unnecessary complication, you are right @weihanglo . i am even wondering why cargo implemented such a thing. |
Problem
for rolling release linux distributions it would be cool to have a quicker way to rebuild all rust packages. building even small applications can take forever. to give an example, there is cosmic desktop. it consists of 15 or so components: https://github.com/pop-os/cosmic-epoch
the dependencies are mostly the same and built again and again.
Proposed Solution
some flag to cargo would be cool which makes every module build of the same workspace. something like
called 15 times should result in reusing everything which was built before. without having a shared lock file, cargo should be intelligent enough to create one by itself.
Notes
No response
The text was updated successfully, but these errors were encountered: