Use an absolute path to C/C++ compilers for better compatibility #104
Conversation
[`toolchains_llvm`][1] only triggers its logic to locate files relative to the compiler wrapper when called with an absolute path, for example. Otherwise it assumes it's being called from the bazel execroot, which is not true in this case. `toolchains_llvm` already has similar logic as `wheel_builder` for mapping paths, which could be used by just calling it with an absolute path instead of using `wheel_builder`'s wrapper, but I think it's easier to use the `wheel_builder` version instead of trying to detect whether the toolchain has this logic. [1]: https://github.com/bazel-contrib/toolchains_llvm/blob/1d685a99db5f1e6523c392e7dfaced583062cbc4/toolchain/cc_wrapper.sh.tpl#L37
|
I can add an integration test that uses |
|
I originally always used absolute paths for everything, but switched to relative paths at some point because I couldn't keep absolute, ephemeral paths from being included in binaries built by I'm not completely happy with the current approach, and have thought about maybe coming up with a way to make the sdist area look like a bazel execroot, allowing all of the bazel relative paths to "just work". Maybe that would solve the llvm issue as well? In either case, I'd happily welcome a |
|
I don't think you can make it look like an execroot in the general case, you might have filename conflicts. uber/hermetic_cc_toolchain#76 sounds like they intend to strip absolute paths regardless of it being called with an absolute path. With this PR, I tried finding any absolute paths after
I ran Sounds good on adding integration tests, I'll push those shortly. |
toolchains_llvmonly triggers its logic to locate files relative to the compiler wrapper when called with an absolute path, for example. Otherwise it assumes it's being called from the bazel execroot, which is not true in this case.toolchains_llvmalready has similar logic aswheel_builderfor mapping paths, which could be used by just calling it with an absolute path instead of usingwheel_builder's wrapper, but I think it's easier to use thewheel_builderversion instead of trying to detect whether the toolchain has this logic.