Join GitHub today
GitHub is home to over 50 million developers working together to host and review code, manage projects, and build software together.
Sign upIs there a way to re-use Servo's Cargo.lock and rustc version from a third party project? #15634
Comments
|
/cc @metajack |
|
cc @aturon I think rustc and cargo can be solved by rust-lang/rustup#460. I seem to recall there was agreement to do this, but noone had time to implement it yet. The bugs paint a more complicated picture. As for copying Cargo.lock (or inheriting or whatever) for a library dependency, this is a non-goal of Cargo, but it seems like we need some kind of tooling for this. |
|
rust-lang/rustup#460 is resolved, so that should only leave the Cargo.lock issue to deal with. @paulrouget Can you confirm that we can now do the rustc override in a useful manner? |
Not yet. The override uses rustup. But afaik, servo doesn't use rustup or local cargo. See #11361 (comment) |
|
So what are our alternatives for the Cargo.lock issue?
Anything else? |
|
Sound good, is there a meta bug for that? Or should we open one? |
|
@shinglyu I don't think there is a bug yet. I'll file one. |
|
Things are moving toward the right direction. We will get to a point where libservo can share its lock file and libservo can require a rustup toolchain. Question: when a third party project wants to use the rustc version of libservo, how do we tell cargo to use libservo's rust toolchain? Would that work automatically? As in, when cargo is called, it will check the dependencies, find the libservo's .rust-toolchain file and make sure it uses that toolchain? |
|
Dependencies so far: |
This issue is part of an effort to improve Servo's embedding story. See https://github.com/paulrouget/servoshell/projects/2
Using libservo in another project requires copying Cargo.lock from Servo, and also make sure we use the same rustc version.
Is there a Cargo mechanism that would improve this?