Skip to content
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.

Sign up for GitHub

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

Jump to bottom

Bug: Workspace giving two different behaviors in Rust #3407

Closed
ustulation opened this issue Dec 15, 2016 · 1 comment · Fixed by #3409
Closed

Bug: Workspace giving two different behaviors in Rust #3407

ustulation opened this issue Dec 15, 2016 · 1 comment · Fixed by #3409

Comments

@ustulation
Copy link

ustulation commented Dec 15, 2016 •
edited
Loading

As explained here :
System:

$uname -r
4.8.0-30-generic

$ lsb_release -a
No LSB modules are available.
Distributor ID: Ubuntu
Description:    Ubuntu 16.10
Release:        16.10
Codename:       yakkety

~$ rustc --version && cargo --version
rustc 1.13.0 (2c6933acc 2016-11-07)
cargo 0.13.0-nightly (eca9e15 2016-11-01)

Steps to reproduce:
Top-level:

    [package]
    name = "workspacer"
    version = "0.1.0"
    authors = ["ustulation <[email protected]>"]
    
    [workspace]
    members = ["safe_core", "safe_authenticator", "safe_app"]
    
    # If this is removed then each of the sub-projects will have thier own Cargo.lock file
    # will build binaries/objects in their own target/ directories. With this present, it's
    # always the parent-projects Cargo.lock and target/ directory used. Need to check if this
    # is standard behaviour or some bug about to be fixed.
    [lib]
    crate_type = ["rlib", "cdylib", "staticlib"]

A lib called safe_core which only needs to produce a .rlib

    [package]
    authors = ["ustulation <[email protected]>"]
    name = "safe_core"
    version = "0.1.0"
    
    [dependencies]
    maidsafe_utilities = "~0.10.0"

A lib called safe_app which depends on safe_core and needs to produce all 3 .rlib, .a and .so:

    [package]
    name = "safe_app"
    version = "0.1.0"
    authors = ["ustulation <[email protected]>"]
    
    [dependencies]
    maidsafe_utilities = "~0.10.0"
    safe_core = { path = "../safe_core" }

    [lib]
    crate_type = ["rlib", "cdylib", "staticlib"]

A lib called safe_authenticator which depends on safe_core and needs to produce all 3 .rlib, .a and .so:

    [package]
    name = "safe_authenticator"
    version = "0.1.0"
    authors = ["ustulation <[email protected]>"]
    
    [dependencies]
    safe_core = { path = "../safe_core" }
    
    [lib]
    crate_type = ["rlib", "cdylib", "staticlib"]

The tree looks like:

    workspacer
    ├── Cargo.toml
    ├── safe_app
    │   ├── Cargo.toml
    │   └── src
    │       └── lib.rs
    ├── safe_authenticator
    │   ├── Cargo.toml
    │   └── src
    │       └── lib.rs
    └── safe_core
        ├── Cargo.toml
        └── src
            └── lib.rs

If I go to safe_core and build, it creates a target/ folder and Cargo.lock files inside the top level workspacer/, which is good.

If I go to safe_authenticator folder and build that it too uses the same target/ and Cargo.lock files and hence does not recompile safe_core which is what I want too. Same with safe_app.

However if I remove the [lib] section from the top-level workspacer/Cargo.toml, each of the sub-projects start creating their own Cargo.lock files and their own /target directories inside their respective sub-directories. I have mentioned this in the inline comment in the Cargo.toml of workspacer above (the 1st snippet above).

So remove the [lib] section from workspacer/Carg.toml as the question says in the inline comment, cd to safe_app/, run cargo test. It will produce safe_app/Cargo.lock and safe_app/target/.... instead of in project dir workspacer.

In-case anyone want to try out, here's the POC repository snapshot at the commit producing the problem.
@matklad
Copy link
Member

matklad commented Dec 15, 2016

Okey, so without [lib] section workspacer/Cargo.toml is an invalid manifest. If you run cargo build in the workspacer dir, you'll get

error: failed to parse manifest at `/home/user/trash/workspacer/Cargo.toml`

Caused by:
  no targets specified in the manifest
  either src/lib.rs, src/main.rs, a [lib] section, or [[bin]] section must be present

And because of this, safe_app does not think that it is within the workspace.

The workaround would be to remove the [package] key from workspacer/Cargo.toml, such that it is a valid so called virtual manifest:

[workspace]
members = ["safe_core", "safe_authenticator", "safe_app"]

However this looks like a bug. Perhaps we should not ignore errors here:

cargo/src/cargo/core/workspace.rs

Line 245 in d902f59

if let Ok(pkg) = self.packages.load(&manifest) {

@matklad matklad mentioned this issue Dec 15, 2016
Merged
bors added a commit that referenced this issue Dec 15, 2016
@bors
Auto merge of #3409 - matklad:workspace-manifest-error, r=alexcrichton
65063c5 
Don't ignore errors in workspace manifest

Closes #3407

If we find `Cargo.toml` during an up tree traversal, we'd better not to ignore errors within it!
@matklad matklad mentioned this issue Mar 1, 2017
Closed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

Successfully merging a pull request may close this issue.

Don't ignore errors in workspace manifest matklad/cargo
2 participants
@matklad @ustulation