Some Travis jobs are not compiling due to OUT_DIR not being present on nightly on my build.rs script. Is this an expected behaviour? how could it be fixed?
Example failure: https://travis-ci.org/SUPERAndroidAnalyzer/super/jobs/181113222#L146
Razican
All 27 comments
I can reproduce this with "cargo install ripgrep" using a cargo built from latest cargo git. Debugging...
joshtriplett
on 5 Dec 2016
Looks like commit 41579bada5c7091e2be1ece45d7f7e02e62fd6b3 caused this issue.
joshtriplett
on 5 Dec 2016
This breaks building servo/rust-bindgen as well.
upsuper
on 7 Dec 2016
cargo even has failing test for me with the same symptoms: http://paste.fedoraproject.org/500936/48110771/
Can't build ripgrep too.
JIghtuse
on 7 Dec 2016
I鈥檝e managed to build bindgen by replacing env! in the build script with std::env::var: https://github.com/servo/rust-bindgen/pull/323
SimonSapin
on 8 Dec 2016
Still, it looks like this is a breaking change. So Cargo should probably revert to providing these variables when compiling a build script. At least for a while, with a warning that this will change.
SimonSapin
on 8 Dec 2016
It looks like commit 95193ca773a668b993891eefe08f3436752b7556 clarified the documentation to state that Cargo doesn't set these environment variables when building the build script, only when running it, even though Cargo did actually set them when building the build script as well. A later commit in Cargo then made the behavior match the documentation.
This does indeed represent a breaking change from the existing behavior, and existing build.rs scripts relied on the existing behavior.
joshtriplett
on 8 Dec 2016
Ah this is definitely an accidental regression! Yes env!("OUT_DIR") is likely not what you want but rather std::env::var is correct in build scripts. The env! version is the out dir that the build script was built with, and the env::var version is for when the build script is being run.
I'm kinda surprised that env! ever worked...
alexcrichton
on 9 Dec 2016
Well... so this was a "regression" but also a bug fix at the same time. The OUT_DIR environment variable can be different when the build script is being compiled compared to when the build script is being run. Notably during cross compilation these two can be different. This means that crates which use env!("OUT_DIR") I believe are broken for cross compiles where crates which use env::var("OUT_DIR") will correctly work with cross compiles.
To those hitting this issue, could you confirm that the crate hasn't been used for cross compiles? And perhaps if it has have weird issues arisen?
We could add a fix for this but I'm tempted to avoid doing so if we can (as it's "incorrect" to rely on the old behavior). If it's possible to fixup the packages in question quickly that'd be best, but if there's ongoing pain then I can change Cargo back to the previous behavior.
alexcrichton
on 9 Dec 2016
@alexcrichton I've seen various crates get fixed for this change (which, at a minimum, needs documentation in release notes).
It'd be good to be able to build existing packages with new Cargo. For the most part, Cargo has maintained backward compatibility across many versions. On the other hand, I do agree that crates shouldn't rely on the old behavior, and it would indeed have broken cross-compiles.
I don't see an obvious way to work-but-warn in this case, without awful hacks (such as somehow substituting in a version of env! that checks the environment variable name and produces a warning).
joshtriplett
on 9 Dec 2016
Yes my only worry is if crates can't be updated. Crates can use std::env::var and work across all versions of Cargo, so if a crate can be proactively updated I'm not too worried about it.
alexcrichton
on 11 Dec 2016
Can crater be used to find out what on crates.io is broken by this change?
SimonSapin
on 11 Dec 2016
@SimonSapin I believe so, yes, we should see it in the next crater run (as soon as it's working)
alexcrichton
on 13 Dec 2016
gazetta-bin-0.1.6 hits this.
brson
on 29 Dec 2016
alexcrichton
on 29 Dec 2016
pinyin-0.0.5 hits this. (Edit: oh you've fixed pinyin)
brson
on 30 Dec 2016
zip_codes-0.0.1 is affected cc @SkylerLipthay
brson
on 30 Dec 2016
Alex fixed this with SkylerLipthay/zip_codes#2, which has been merged! zip_codes 0.1.0 was subsequently released.
SkylerLipthay
on 31 Dec 2016
Affects rasen-0.1.0
https://tools.taskcluster.net/task-inspector/#_6XeY7pIRjKvuBDVVuFMFQ/0
brson
on 31 Dec 2016
Great @SkylerLipthay! Sorry for the inconvenience.
brson
on 31 Dec 2016
@brson I think pinyin and rasen were both addressed here -- https://github.com/rust-lang/rust/issues/38391#issuecomment-269524203
alexcrichton
on 31 Dec 2016
lmdb-rs 0.7.3's test suite is affected. cc @vhbit
brson
on 5 Jan 2017
@brson looks like that was fixed by https://github.com/vhbit/lmdb-rs/commit/25c1fdc71f3ee1099de4341cf165532f57f94dea
alexcrichton
on 6 Jan 2017
Ok we've decided to close this as working as intended, but if any projects need help migrating please just let me know!
alexcrichton
on 12 Jan 2017
@alexcrichton The story isn't over, however: https://github.com/abonander/mime_guess/issues/33
This invocation is at the build time of the crate: https://github.com/abonander/mime_guess/blob/master/src/lib.rs#L16
When OUT_DIR should be defined at that point because there is a build script.
abonander
on 12 Mar 2018
@abonander maybe the version of Cargo there is too old to recognize the implicit build script via build.rs?
alexcrichton
on 12 Mar 2018
@alexcrichton Good call! The issue reporter was running a Docker container with a super-outdated Cargo.
abonander
on 12 Mar 2018
Related issues
sdroege
路
3Comments
skletsun
路
3Comments
dotnetspec
路
3Comments
rodoufu
路
3Comments
aturon
路
3Comments
Most helpful comment
I can reproduce this with "cargo install ripgrep" using a cargo built from latest cargo git. Debugging...