Code compiles on playground but fails when passed via stdin to rustc

41

My first thought would be "what directory is that cargo config executing under?", I would kind of expect build-script-run to use the manifest-dir of the defining crate, while the config you care about is the top-level build.

EDIT: which leads into the second question: "if this is cached and reused for a different build with a different config, how does it invalidate the cache?" (since there's no rerun-if-changed for cargo config).

42

My assumption was the current working directory where cargo build/test/run was invoked. You were right, and I found it in the cargo docs after manually debugging via one of my other crates.

Thanks for the tip.

The best solution I could come up with is[1]:

  • This will obtain config.toml files based upon OUT_DIR. If this is not under the project root, you can override by providing an alternative path via the environment variable NINJA_CARGO_CONFIG_DIR. See cargo’s documentation on config file hierarchical structure for more details.

To my view that now respects the standard expectations of the cumulative opt-in approach taken by rustc & cargo:

  1. opt-in to unstable features via toolchain (all features available)
  2. opt-in to granular opt-in by specifying allow-features (empty whitelist - no features available)
  3. opt-in to specific features (only whitelisted features available)

If you have a suitable trigger for this I'd be happy to add it. How do you trigger a rebuild of your own crate when you update any of the relevant config.tomls`? - the config change is potentially equally relevant there...

  1. both documented in the crate docs under "Note to downstream crates" and designed to be obvious in the code ↩︎