Skip to content
This repository has been archived by the owner on Jun 21, 2019. It is now read-only.

Support for vendoring on a single platform #70

Closed
nipunn1313 opened this issue Apr 11, 2018 · 2 comments
Closed

Support for vendoring on a single platform #70

nipunn1313 opened this issue Apr 11, 2018 · 2 comments

Comments

@nipunn1313
Copy link
Contributor

Hi,

At Dropbox, we have a desktop client use case which requires cargo-vendor to vendor deps across all platforms (cargo-vendor is great here)

We also have a server use case in which we'd prefer to vendor deps just for linux (currently, we end up pulling in some windows-specific deps, some of which are quite large (eg 50MB of .a files here https://github.com/retep998/winapi-rs/tree/0.3/i686/lib)

Currently cargo-vendor will pull in optional windows dependencies even if we don't need them. I believe this happens in resolve_ws here https://github.com/rust-lang/cargo/blob/master/src/cargo/ops/resolve.rs#L16

It would be great to have an option to exclude windows-specific dependencies for cases where we know we're only building for linux.

@alexcrichton
Copy link
Owner

Certainly a feature I'd like to implement! Supporting this will be pretty difficult though, unfortunately. Cargo currently requires that the lock file is platform-independent, meaning that the lock file (and generating the lock file) always has to locate all crates for all possible platforms. This means that if you were to remove the winapi folder, for example, then a lock file would no longer be correctly generated.

There's a tracking issue for this at rust-lang/cargo#5133 which is a possible way to pass a flag to Cargo and say "please generate a minimal lock file", and with that we can safely delete all the dependencies for other platforms.

@alexcrichton
Copy link
Owner

This crate is now included natively in Cargo as of rust-lang/cargo#6869 and today's nightly Rust. I'm closing all issues in this repository before I archive the repository, but if you're still interested in seeing this issue fixed then please feel free to file an issue with Cargo itself!

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants