Skip to content

Dependencies referenced by path. #139

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
jD91mZM2 opened this issue Oct 17, 2017 · 4 comments
Closed

Dependencies referenced by path. #139

jD91mZM2 opened this issue Oct 17, 2017 · 4 comments

Comments

@jD91mZM2
Copy link

Example:

crate = { path = "../crate" }

This fails with

error: failed to load source for a dependency on `crate`

Caused by:
  Unable to update file:///crate

Caused by:
  failed to read `/crate/Cargo.toml`

Caused by:
  No such file or directory (os error 2)
@japaric
Copy link
Contributor

japaric commented Oct 17, 2017

This is expected and documented in the README.

@japaric japaric closed this as completed Oct 17, 2017
@jD91mZM2
Copy link
Author

Sorry, my bad

@gnzlbg
Copy link
Contributor

gnzlbg commented Jul 13, 2018

If one has the following structure:

  • root_crate/
    • src/
    • examples/
      • example_crate/
        • src/

where example_crate uses path = ../../ to refer to the root crate, and one executes from the root_crate: cross test -p examples/example_crate this should work though as long as example_crate is part of the root_crate's workspace.

However, if one excludes example_crate from the root_crate's workspace, then doing cross test --manifest-path examples/example_crate will fail, because that will try to write a Cargo.lock into the examples/example_crate directory, which is read only.

If we had an option to mount the root_crate's directory as read-write in the Docker containers, that should work too.

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]>
@Alexhuszagh
Copy link
Contributor

This was fully implemented in #684.

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

No branches or pull requests

4 participants