| commit | efb2b80953983dce499d453a9f55a74ffaf8c42d | [log] [tgz] |
|---|---|---|
| author | Andreas Herrmann <andreash87@gmx.ch> | Mon Mar 21 08:04:51 2022 -0700 |
| committer | Copybara-Service <copybara-worker@google.com> | Mon Mar 21 08:06:18 2022 -0700 |
| tree | 730154d6a3fae633089864ee0bb03992dd1f6650 | |
| parent | 7812bdce946578e8630af433d78ac2a0e8b8cb2f [diff] |
osx_cc_wrapper: Only expand existing response files Closes #13044 Applies the changes suggested in https://github.com/bazelbuild/bazel/pull/13044#issuecomment-783539568 Not all arguments starting with `@` represent response files, e.g. `-install_name @rpath/...` or `-Xlinker -rpath -Xlinker @loader_path/...` do not refer to response files and attempting to read them as such will fail the build. Users don't always have control over these arguments, meaning transforming them to `-Wl,-install_name,@rpath/...` or `-Wl,-rpath,@loader_path/...` is not always an option. E.g. as described in https://github.com/bazelbuild/bazel/pull/13044#issuecomment-779380394 where these flags are emitted by the Haskell compiler GHC (see https://github.com/bazelbuild/bazel/pull/13044#issuecomment-782228172 for their reasoning). With this change `osx_cc_wrapper` will only interpret arguments starting with `@` as response files if the corresponding file exists and is readable. This is analogous to the behavior defined in `wrapped_clang.cc`. See https://github.com/bazelbuild/bazel/pull/13044#issuecomment-783539568 for discussion. Closes #13148. PiperOrigin-RevId: 436207868
{Fast, Correct} - Choose two
Build and test software of any size, quickly and reliably.
Speed up your builds and tests: Bazel rebuilds only what is necessary. With advanced local and distributed caching, optimized dependency analysis and parallel execution, you get fast and incremental builds.
One tool, multiple languages: Build and test Java, C++, Android, iOS, Go, and a wide variety of other language platforms. Bazel runs on Windows, macOS, and Linux.
Scalable: Bazel helps you scale your organization, codebase, and continuous integration solution. It handles codebases of any size, in multiple repositories or a huge monorepo.
Extensible to your needs: Easily add support for new languages and platforms with Bazel's familiar extension language. Share and re-use language rules written by the growing Bazel community.
Follow our tutorials:
To report a security issue, please email security@bazel.build with a description of the issue, the steps you took to create the issue, affected versions, and, if known, mitigations for the issue. Our vulnerability management team will respond within 3 working days of your email. If the issue is confirmed as a vulnerability, we will open a Security Advisory. This project follows a 90 day disclosure timeline.
See CONTRIBUTING.md
