nix-community / crate2nix

rebuild only changed crates in CI with crate2nix and nix
https://nix-community.github.io/crate2nix/
Apache License 2.0
387 stars 88 forks source link

crate2nix attempts to build binaries without their target-specific required-features #129

Open JJJollyjim opened 4 years ago

JJJollyjim commented 4 years ago

For example, try generating and building https://github.com/aahancoc/tree_magic/tarball/0.2.3

The binary fails to build since it can't find clap. Here's the relevant Cargo.toml snippet:

[features]
cli = ["clap", "tabwriter", "scoped_threadpool", "walkdir", "num_cpus"]
# ...
default = []

[lib]
crate-type = ["lib"]
path = "src/lib.rs"

[[bin]]
required-features = ["cli"]
name = "tmagic"
path = "src/main.rs"

And here's the diffedDefaultPackageFeatures:

{
  "differentFeatures": {},
  "onlyInCargo": [
    "ansi_term",
    "atty",
    "bitflags",
    "clap",
    "cloudabi",
    "hermit-abi",
    "num_cpus",
    "redox_syscall",
    "same-file",
    "scoped_threadpool",
    "strsim",
    "tabwriter",
    "textwrap",
    "unicode-width",
    "vec_map",
    "walkdir",
    "winapi",
    "winapi-i686-pc-windows-gnu",
    "winapi-util",
    "winapi-x86_64-pc-windows-gnu"
  ],
  "onlyInCrate2Nix": []
}

Thanks :)

kolloch commented 4 years ago

Thank you for the report!

Oh, yeah, at a first glance, I'd say this is unsupported. I was unaware of this feature. Target-specific features. Makes sense. ;)

You can probably workaround this limitation easily by enabling the relevant features at the build root manually:

https://github.com/kolloch/crate2nix#dynamic-feature-resolution

Tell me if that works for you!

JJJollyjim commented 4 years ago

Yep, the workaround definitely works :)

I've now properly investigated Cargo's default behavior (I assumed it would automatically enable the feature), but it turns out to match crate2nix pretty well, except with a nice error instead of attempting to build:

$ cargo build --bin=tmagic
error: target `tmagic` in package `tree_magic` requires the features: `cli`
Consider enabling them by passing, e.g., `--features="cli"`

Or, using cargo install

$ cargo install tree_magic
    Updating crates.io index
  Installing tree_magic v0.2.3
   Compiling libc v0.2.69
   Compiling autocfg v1.0.0
   Compiling smallvec v1.4.0
   Compiling cfg-if v0.1.10
   Compiling scopeguard v1.1.0
   Compiling fixedbitset v0.2.0
   Compiling fnv v1.0.6
   Compiling lazy_static v1.4.0
   Compiling indexmap v1.3.2
   Compiling lock_api v0.3.4
   Compiling petgraph v0.5.0
   Compiling parking_lot_core v0.7.2
   Compiling memchr v1.0.2
   Compiling nom v3.2.1
   Compiling parking_lot v0.10.2
   Compiling tree_magic v0.2.3
    Finished release [optimized] target(s) in 9.81s
error: no binaries are available for install using the selected features
kolloch commented 4 years ago

Ah, OK, if we copied this behavior:

yusdacra commented 3 years ago

I encountered this issue while I was performing usual Cargo.nix regeneration on the Veloren project. The suggested workaround did not work for me, so I resorted to manually commenting the optional = true; from the relevant dependencies as a workaround. I'd like to fix this issue in crate2nix, but I'm not sure where to start, so some pointers would be great :D

EDIT: The cargo behaviour can be reproduced on the master branch currently by running cargo build --bin=csv_export.