error: failed to read src/tools/cargo/Cargo.toml #40284
Comments
|
Can be fixed by See #39917 (comment) |
|
I've sent a PR to fix this |
frewsxcv
added a commit
to frewsxcv/rust
that referenced
this issue
Mar 9, 2017
Don't put Cargo into the rustc workspace This causes problems when first cloning and bootstrapping the repository unfortunately, so let's ensure that Cargo sticks around in its own workspace. Because Cargo is a submodule it's not available by default on the inital clone of the rust-lang/rust repository. Normally it's the responsibility of the rustbuild to take care of this, but unfortunately to build rustbuild itself we need to resolve the workspace conflicts. To deal with this we'll just have to ensure that all submodules are in their own workspace, which sort of makes sense anyway as updates to dependencies as bugfixes to Cargo should go to rust-lang/cargo instead of rust-lang/rust. In any case this commit removes Cargo from the global workspace which should resolve the issues that we've been seeing. To actually perform this the `cargo` submodule has been moved to a new `vendor` directory to ensure it's outside the scope of `src/Cargo.toml` as a workspace. Closes rust-lang#40284
alexcrichton
added a commit
to alexcrichton/rust
that referenced
this issue
Mar 10, 2017
Don't put Cargo into the rustc workspace This causes problems when first cloning and bootstrapping the repository unfortunately, so let's ensure that Cargo sticks around in its own workspace. Because Cargo is a submodule it's not available by default on the inital clone of the rust-lang/rust repository. Normally it's the responsibility of the rustbuild to take care of this, but unfortunately to build rustbuild itself we need to resolve the workspace conflicts. To deal with this we'll just have to ensure that all submodules are in their own workspace, which sort of makes sense anyway as updates to dependencies as bugfixes to Cargo should go to rust-lang/cargo instead of rust-lang/rust. In any case this commit removes Cargo from the global workspace which should resolve the issues that we've been seeing. To actually perform this the `cargo` submodule has been moved to a new `vendor` directory to ensure it's outside the scope of `src/Cargo.toml` as a workspace. Closes rust-lang#40284
alexcrichton
pushed a commit
to arielb1/rust
that referenced
this issue
Mar 10, 2017
Don't put Cargo into the rustc workspace This causes problems when first cloning and bootstrapping the repository unfortunately, so let's ensure that Cargo sticks around in its own workspace. Because Cargo is a submodule it's not available by default on the inital clone of the rust-lang/rust repository. Normally it's the responsibility of the rustbuild to take care of this, but unfortunately to build rustbuild itself we need to resolve the workspace conflicts. To deal with this we'll just have to ensure that all submodules are in their own workspace, which sort of makes sense anyway as updates to dependencies as bugfixes to Cargo should go to rust-lang/cargo instead of rust-lang/rust. In any case this commit removes Cargo from the global workspace which should resolve the issues that we've been seeing. To actually perform this the `cargo` submodule has been moved to a new `vendor` directory to ensure it's outside the scope of `src/Cargo.toml` as a workspace. Closes rust-lang#40284
alexcrichton
added a commit
to alexcrichton/rust
that referenced
this issue
Mar 10, 2017
Don't put Cargo into the rustc workspace This causes problems when first cloning and bootstrapping the repository unfortunately, so let's ensure that Cargo sticks around in its own workspace. Because Cargo is a submodule it's not available by default on the inital clone of the rust-lang/rust repository. Normally it's the responsibility of the rustbuild to take care of this, but unfortunately to build rustbuild itself we need to resolve the workspace conflicts. To deal with this we'll just have to ensure that all submodules are in their own workspace, which sort of makes sense anyway as updates to dependencies as bugfixes to Cargo should go to rust-lang/cargo instead of rust-lang/rust. In any case this commit removes Cargo from the global workspace which should resolve the issues that we've been seeing. To actually perform this the `cargo` submodule has been moved to a new `vendor` directory to ensure it's outside the scope of `src/Cargo.toml` as a workspace. Closes rust-lang#40284
arielb1
pushed a commit
to arielb1/rust
that referenced
this issue
Mar 10, 2017
Don't put Cargo into the rustc workspace This causes problems when first cloning and bootstrapping the repository unfortunately, so let's ensure that Cargo sticks around in its own workspace. Because Cargo is a submodule it's not available by default on the inital clone of the rust-lang/rust repository. Normally it's the responsibility of the rustbuild to take care of this, but unfortunately to build rustbuild itself we need to resolve the workspace conflicts. To deal with this we'll just have to ensure that all submodules are in their own workspace, which sort of makes sense anyway as updates to dependencies as bugfixes to Cargo should go to rust-lang/cargo instead of rust-lang/rust. In any case this commit removes Cargo from the global workspace which should resolve the issues that we've been seeing. To actually perform this the `cargo` submodule has been moved to a new `vendor` directory to ensure it's outside the scope of `src/Cargo.toml` as a workspace. Closes rust-lang#40284
arielb1
pushed a commit
to arielb1/rust
that referenced
this issue
Mar 10, 2017
Don't put Cargo into the rustc workspace This causes problems when first cloning and bootstrapping the repository unfortunately, so let's ensure that Cargo sticks around in its own workspace. Because Cargo is a submodule it's not available by default on the inital clone of the rust-lang/rust repository. Normally it's the responsibility of the rustbuild to take care of this, but unfortunately to build rustbuild itself we need to resolve the workspace conflicts. To deal with this we'll just have to ensure that all submodules are in their own workspace, which sort of makes sense anyway as updates to dependencies as bugfixes to Cargo should go to rust-lang/cargo instead of rust-lang/rust. In any case this commit removes Cargo from the global workspace which should resolve the issues that we've been seeing. To actually perform this the `cargo` submodule has been moved to a new `vendor` directory to ensure it's outside the scope of `src/Cargo.toml` as a workspace. Closes rust-lang#40284
alexcrichton
added a commit
to alexcrichton/rust
that referenced
this issue
Mar 11, 2017
Don't put Cargo into the rustc workspace This causes problems when first cloning and bootstrapping the repository unfortunately, so let's ensure that Cargo sticks around in its own workspace. Because Cargo is a submodule it's not available by default on the inital clone of the rust-lang/rust repository. Normally it's the responsibility of the rustbuild to take care of this, but unfortunately to build rustbuild itself we need to resolve the workspace conflicts. To deal with this we'll just have to ensure that all submodules are in their own workspace, which sort of makes sense anyway as updates to dependencies as bugfixes to Cargo should go to rust-lang/cargo instead of rust-lang/rust. In any case this commit removes Cargo from the global workspace which should resolve the issues that we've been seeing. To actually perform this the `cargo` submodule has been moved to a new `vendor` directory to ensure it's outside the scope of `src/Cargo.toml` as a workspace. Closes rust-lang#40284
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
The
src/tools/cargodirectory is empty. Cleaning the checkout (withgit clean -f -x -d) and runningconfigureagain didn't fix it.Configure command line:
./configure --prefix=/home/cesarb/opt/rust-git --android-cross-path=/home/cesarb/android-sdks/temp/arm-linux-androideabi --target=x86_64-unknown-linux-gnu,i686-unknown-linux-gnu,x86_64-pc-windows-gnu,arm-linux-androideabi,armv7-linux-androideabiThe text was updated successfully, but these errors were encountered: