Preserve project working directory #78
Closed
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
|
Thanks for the PR, @dflemstr. Could you elaborate on this:
Surely those build scripts are using relative paths rather than absolute paths; otherwise, they wouldn't be portable across machines.
That it's already the case, right? Everything within the project directory gets mounted into the Docker container. The project can't refer to anything outside of it because it's not mounted. Changing on which directory the Cargo project will get mounted inside the docker cointainer won't change that. |
|
@dflemstr: You may want to consider making a Cargo Workspace containing all of your code. Check out this documentation: https://doc.rust-lang.org/book/second-edition/ch14-03-cargo-workspaces.html Once you have made a cargo workspace, you can make the following call from the root of the workspace:
I was able to use this to build my crate with local source dependencies. |
|
The reason why this is needed is because I need to link some (C++) libraries that are built outside of the container. Sadly I can't do this with relative paths since the libraries are needed for a dependency far down the dependency path of my crate, and each dependency crate is built with its own manifest directory as the current working directory. |
|
@dflemstr can you build those crates inside the container using a Or do you have an example of a project layout where this happens? (no handwaving, but maybe a link to a concrete github repo with step-by-step explanation?) |
|
@gnzlbg the building of the particular C++ codebase takes about 30-50 minutes so I would prefer to not do it on every cargo build if possible :) |
|
@dflemstr so your build script then depends on how the directories outside of your crate are set up ? |
|
Closing this as there are existing alternative ways of doing this. If you are still keen on including it, you can open a new PR. |
wngr
added a commit
to wngr/cross
that referenced
this pull request
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 <alex@kviring.com>
datdenkikniet
pushed a commit
to datdenkikniet/cross
that referenced
this pull request
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 <alex@kviring.com>
wngr
added a commit
to wngr/cross
that referenced
this pull request
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 <alex@kviring.com>
Emilgardis
pushed a commit
to Emilgardis/cross
that referenced
this pull request
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 <alex@kviring.com>
Emilgardis
pushed a commit
to Emilgardis/cross
that referenced
this pull request
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 <alex@kviring.com>
Emilgardis
pushed a commit
to Emilgardis/cross
that referenced
this pull request
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 <alex@kviring.com>
Emilgardis
pushed a commit
to Emilgardis/cross
that referenced
this pull request
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 <alex@kviring.com>
Emilgardis
pushed a commit
to Emilgardis/cross
that referenced
this pull request
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 <alex@kviring.com>
Emilgardis
pushed a commit
to Emilgardis/cross
that referenced
this pull request
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 <alex@kviring.com>
Emilgardis
pushed a commit
to Emilgardis/cross
that referenced
this pull request
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 <alex@kviring.com>
Emilgardis
pushed a commit
to Emilgardis/cross
that referenced
this pull request
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 <alex@kviring.com>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Some build scripts rely on references into the working directory of the project being built, so the project directory should be the same inside and outside the docker container.