Wanted to start a discussion to understand if this is desired and if there are any flaws I'm missing.
In a large iOS codebase one of our targets hits a "Argument list too long" failure when building in Xcode due to a very large list of compiler flags being set in the OTHER_SWIFT_FLAGS build setting. While we work to simplify the build graph and reduce the number of flags needed to compile such target we might have to consider alternative ways to mitigate the issue.
After seeing this discussion in the Bazel slack decided to try to come up with a PoC minimal enough so I can test things in Xcode. Here's a draft branch:
thiago/clang-config-in-other-swift-flags
- This effectively sends all
clang flags to a clang.params file and sets -Xcc --config=path/to/foo.clang.params in OTHER_SWIFT_FLAGS
- The key changes are in
ProcessSwiftArgs.swift, the rest is just there to generate the file with Bazel and make bazel test //... pass in the repo
I've been experimenting with this commit internally and so far most basic interactions in Xcode seem to work fine and I'm able to build big targets without hitting the "Argument list too long" issue.
That said, main concerns I'd appreciate feedback on:
- Is this desired by others and worth adding as an experimental feature?
- Would indexing work reliably with this approach?
- Would LLDB work reliably with this approach?
- Would the overhead introduced to generate files be acceptable?
- Any hard blocker I'm missing?