The original usage and unfortunate linage of xcconfig for diagnostics is documented on github:
https://github.com/pinterest/xchammer/blob/master/Docs/FastAndReproducibleBuildsWithXCHammer.md#diagnostics
We're stuck with this because there isn't a great way to turn off default flags in Xcode without xcconfig.
Therefore, we use xcconfig to sync up Xcode with Bazel. When we migrated to Bazel we generated .bzl files to represent xcconfig. Today, we manually sync up xcconfig and .bzl when the diags change.
The program mentioned in the doc is included with xchammer now and devs have used this in the past when they refactored diagnostic settings. These diagnostic settings don't often have a reason to change
tools/XCConfigExporter:xcconfig-exporter
Ideally, we can have a solution to disable defaults and sidestep this problem without significant runtime patches. Otherwise, I image an xcconfig evaluator could be integrated as a repository rule or toolchain.
The original usage and unfortunate linage of xcconfig for diagnostics is documented on github:
https://github.com/pinterest/xchammer/blob/master/Docs/FastAndReproducibleBuildsWithXCHammer.md#diagnostics
We're stuck with this because there isn't a great way to turn off default flags in Xcode without xcconfig.
Therefore, we use xcconfig to sync up Xcode with Bazel. When we migrated to Bazel we generated
.bzlfiles to representxcconfig. Today, we manually sync upxcconfigand.bzlwhen the diags change.The program mentioned in the doc is included with xchammer now and devs have used this in the past when they refactored diagnostic settings. These diagnostic settings don't often have a reason to change
Ideally, we can have a solution to disable defaults and sidestep this problem without significant runtime patches. Otherwise, I image an xcconfig evaluator could be integrated as a repository rule or toolchain.