Supporting relative path in Cargo.toml depends #277
Labels
Comments
|
This is a duplicate of #139. |
|
Thanks for opening the issue (and sorry about the delays) From the readme:
So right now it wouldn't be possible to make this change without making a major change in how |
wngr
added a commit
to wngr/cross
that referenced
this issue
Dec 4, 2020
…ker root
This commits adds support for parsing the `--manifest-path` option to cross. So
far, the `Cargo.toml` manifest of the crate (or its Cargo workspace) to compile
has been assumed to be in the current working directory. This means, that
relative crate dependencies were not supported, because those paths were not
mapped into the docker container.
Take the following example structure, where `my-bin` depends on `my-lib`:
.
├── my-bin
│ ├── Cargo.toml
│ └── src
│ └── main.rs
└── my-lib
├── Cargo.toml
└── src
└── lib.rs
This commits enables such scenarios, by running cross from `.` like so:
`cross build --manifest-path=my-lib/Cargo.toml --target x86_64-pc-windows-gnu`,
as `.` is mapped as the container's root, and the options passed through to
Cargo.
Related cross-rs#388 cross-rs#139 cross-rs#277 cross-rs#78
Co-authored-by: Kviring Alexey <[email protected]>
datdenkikniet
pushed a commit
to datdenkikniet/cross
that referenced
this issue
Jan 28, 2022
…ker root
This commits adds support for parsing the `--manifest-path` option to cross. So
far, the `Cargo.toml` manifest of the crate (or its Cargo workspace) to compile
has been assumed to be in the current working directory. This means, that
relative crate dependencies were not supported, because those paths were not
mapped into the docker container.
Take the following example structure, where `my-bin` depends on `my-lib`:
.
├── my-bin
│ ├── Cargo.toml
│ └── src
│ └── main.rs
└── my-lib
├── Cargo.toml
└── src
└── lib.rs
This commits enables such scenarios, by running cross from `.` like so:
`cross build --manifest-path=my-lib/Cargo.toml --target x86_64-pc-windows-gnu`,
as `.` is mapped as the container's root, and the options passed through to
Cargo.
Related cross-rs#388 cross-rs#139 cross-rs#277 cross-rs#78
Co-authored-by: Kviring Alexey <[email protected]>
wngr
added a commit
to wngr/cross
that referenced
this issue
Mar 19, 2022
root
This commits adds support for parsing the `--manifest-path` option to cross. So
far, the `Cargo.toml` manifest of the crate (or its Cargo workspace) to compile
has been assumed to be in the current working directory. This means, that
relative crate dependencies were not supported, because those paths were not
mapped into the docker container.
Take the following example structure, where `my-bin` depends on `my-lib`:
.
├── my-bin
│ ├── Cargo.toml
│ └── src
│ └── main.rs
└── my-lib
├── Cargo.toml
└── src
└── lib.rs
This commits enables such scenarios, by running cross from `.` like so:
`cross build --manifest-path=my-lib/Cargo.toml --target x86_64-pc-windows-gnu`,
as `.` is mapped as the container's root, and the options passed through to
Cargo.
Related cross-rs#388 cross-rs#139 cross-rs#277 cross-rs#78
Co-authored-by: Kviring Alexey <[email protected]>
Emilgardis
pushed a commit
to Emilgardis/cross
that referenced
this issue
Apr 7, 2022
root
This commits adds support for parsing the `--manifest-path` option to cross. So
far, the `Cargo.toml` manifest of the crate (or its Cargo workspace) to compile
has been assumed to be in the current working directory. This means, that
relative crate dependencies were not supported, because those paths were not
mapped into the docker container.
Take the following example structure, where `my-bin` depends on `my-lib`:
.
├── my-bin
│ ├── Cargo.toml
│ └── src
│ └── main.rs
└── my-lib
├── Cargo.toml
└── src
└── lib.rs
This commits enables such scenarios, by running cross from `.` like so:
`cross build --manifest-path=my-lib/Cargo.toml --target x86_64-pc-windows-gnu`,
as `.` is mapped as the container's root, and the options passed through to
Cargo.
Related cross-rs#388 cross-rs#139 cross-rs#277 cross-rs#78
Co-authored-by: Kviring Alexey <[email protected]>
Emilgardis
pushed a commit
to Emilgardis/cross
that referenced
this issue
Apr 7, 2022
root
This commits adds support for parsing the `--manifest-path` option to cross. So
far, the `Cargo.toml` manifest of the crate (or its Cargo workspace) to compile
has been assumed to be in the current working directory. This means, that
relative crate dependencies were not supported, because those paths were not
mapped into the docker container.
Take the following example structure, where `my-bin` depends on `my-lib`:
.
├── my-bin
│ ├── Cargo.toml
│ └── src
│ └── main.rs
└── my-lib
├── Cargo.toml
└── src
└── lib.rs
This commits enables such scenarios, by running cross from `.` like so:
`cross build --manifest-path=my-lib/Cargo.toml --target x86_64-pc-windows-gnu`,
as `.` is mapped as the container's root, and the options passed through to
Cargo.
Related cross-rs#388 cross-rs#139 cross-rs#277 cross-rs#78
Co-authored-by: Kviring Alexey <[email protected]>
Emilgardis
pushed a commit
to Emilgardis/cross
that referenced
this issue
Apr 29, 2022
root
This commits adds support for parsing the `--manifest-path` option to cross. So
far, the `Cargo.toml` manifest of the crate (or its Cargo workspace) to compile
has been assumed to be in the current working directory. This means, that
relative crate dependencies were not supported, because those paths were not
mapped into the docker container.
Take the following example structure, where `my-bin` depends on `my-lib`:
.
├── my-bin
│ ├── Cargo.toml
│ └── src
│ └── main.rs
└── my-lib
├── Cargo.toml
└── src
└── lib.rs
This commits enables such scenarios, by running cross from `.` like so:
`cross build --manifest-path=my-lib/Cargo.toml --target x86_64-pc-windows-gnu`,
as `.` is mapped as the container's root, and the options passed through to
Cargo.
Related cross-rs#388 cross-rs#139 cross-rs#277 cross-rs#78
Co-authored-by: Kviring Alexey <[email protected]>
Emilgardis
pushed a commit
to Emilgardis/cross
that referenced
this issue
May 20, 2022
root
This commits adds support for parsing the `--manifest-path` option to cross. So
far, the `Cargo.toml` manifest of the crate (or its Cargo workspace) to compile
has been assumed to be in the current working directory. This means, that
relative crate dependencies were not supported, because those paths were not
mapped into the docker container.
Take the following example structure, where `my-bin` depends on `my-lib`:
.
├── my-bin
│ ├── Cargo.toml
│ └── src
│ └── main.rs
└── my-lib
├── Cargo.toml
└── src
└── lib.rs
This commits enables such scenarios, by running cross from `.` like so:
`cross build --manifest-path=my-lib/Cargo.toml --target x86_64-pc-windows-gnu`,
as `.` is mapped as the container's root, and the options passed through to
Cargo.
Related cross-rs#388 cross-rs#139 cross-rs#277 cross-rs#78
Co-authored-by: Kviring Alexey <[email protected]>
Emilgardis
pushed a commit
to Emilgardis/cross
that referenced
this issue
May 26, 2022
root
This commits adds support for parsing the `--manifest-path` option to cross. So
far, the `Cargo.toml` manifest of the crate (or its Cargo workspace) to compile
has been assumed to be in the current working directory. This means, that
relative crate dependencies were not supported, because those paths were not
mapped into the docker container.
Take the following example structure, where `my-bin` depends on `my-lib`:
.
├── my-bin
│ ├── Cargo.toml
│ └── src
│ └── main.rs
└── my-lib
├── Cargo.toml
└── src
└── lib.rs
This commits enables such scenarios, by running cross from `.` like so:
`cross build --manifest-path=my-lib/Cargo.toml --target x86_64-pc-windows-gnu`,
as `.` is mapped as the container's root, and the options passed through to
Cargo.
Related cross-rs#388 cross-rs#139 cross-rs#277 cross-rs#78
Co-authored-by: Kviring Alexey <[email protected]>
Emilgardis
pushed a commit
to Emilgardis/cross
that referenced
this issue
Jun 2, 2022
root
This commits adds support for parsing the `--manifest-path` option to cross. So
far, the `Cargo.toml` manifest of the crate (or its Cargo workspace) to compile
has been assumed to be in the current working directory. This means, that
relative crate dependencies were not supported, because those paths were not
mapped into the docker container.
Take the following example structure, where `my-bin` depends on `my-lib`:
.
├── my-bin
│ ├── Cargo.toml
│ └── src
│ └── main.rs
└── my-lib
├── Cargo.toml
└── src
└── lib.rs
This commits enables such scenarios, by running cross from `.` like so:
`cross build --manifest-path=my-lib/Cargo.toml --target x86_64-pc-windows-gnu`,
as `.` is mapped as the container's root, and the options passed through to
Cargo.
Related cross-rs#388 cross-rs#139 cross-rs#277 cross-rs#78
Co-authored-by: Kviring Alexey <[email protected]>
Emilgardis
pushed a commit
to Emilgardis/cross
that referenced
this issue
Jun 3, 2022
root
This commits adds support for parsing the `--manifest-path` option to cross. So
far, the `Cargo.toml` manifest of the crate (or its Cargo workspace) to compile
has been assumed to be in the current working directory. This means, that
relative crate dependencies were not supported, because those paths were not
mapped into the docker container.
Take the following example structure, where `my-bin` depends on `my-lib`:
.
├── my-bin
│ ├── Cargo.toml
│ └── src
│ └── main.rs
└── my-lib
├── Cargo.toml
└── src
└── lib.rs
This commits enables such scenarios, by running cross from `.` like so:
`cross build --manifest-path=my-lib/Cargo.toml --target x86_64-pc-windows-gnu`,
as `.` is mapped as the container's root, and the options passed through to
Cargo.
Related cross-rs#388 cross-rs#139 cross-rs#277 cross-rs#78
Co-authored-by: Kviring Alexey <[email protected]>
Emilgardis
pushed a commit
to Emilgardis/cross
that referenced
this issue
Jun 3, 2022
root
This commits adds support for parsing the `--manifest-path` option to cross. So
far, the `Cargo.toml` manifest of the crate (or its Cargo workspace) to compile
has been assumed to be in the current working directory. This means, that
relative crate dependencies were not supported, because those paths were not
mapped into the docker container.
Take the following example structure, where `my-bin` depends on `my-lib`:
.
├── my-bin
│ ├── Cargo.toml
│ └── src
│ └── main.rs
└── my-lib
├── Cargo.toml
└── src
└── lib.rs
This commits enables such scenarios, by running cross from `.` like so:
`cross build --manifest-path=my-lib/Cargo.toml --target x86_64-pc-windows-gnu`,
as `.` is mapped as the container's root, and the options passed through to
Cargo.
Related cross-rs#388 cross-rs#139 cross-rs#277 cross-rs#78
Co-authored-by: Kviring Alexey <[email protected]>
|
This was fully fixed in #684. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
How would one do this, currently I am building the entire workspace, which makes it work, but then other tools doesn't work since they do not support workspaces it seems
The text was updated successfully, but these errors were encountered: