If all you've got is Xcode, your only tool is a 🔨
XCHammer generates Xcode projects from a Bazel Workspace.
Note: this README is intended to be a minimal, quick start guide to XCHammer. To learn more about XCHammer see Introducing XCHammer and The XCHammer FAQ. To learn more about Bazel, see Bazel for iOS developers. To learn about how Pinterest uses XCHammer see Introducing XCHammer and Pinterest Focused Xcode Projects
First, pull XCHammer into the
Ideally, pull in a release optimized binary build to keep XCHammer's dependencies, Swift version, Xcode version, compiler flags, Bazel version, and build time outside of the main iOS/macOS application's WORKSPACE. To easily achieve this, GitHub CI creates a binary release artifact on receiving a new tag.
# WORKSPACE # Recommended approach - the CI auto releases when you push a tag matching `v*` # The release prefix is the _tested_ bazel version, and XCHammer is often # forwards and backwards compatible http_archive( name = "xchammer", urls = [ "https://github.com/pinterest/xchammer/releases/download/v126.96.36.199/xchammer.zip" ], )
Next, create an
xcode_project target including targets:
# BUILD.Bazel load("@xchammer//:xcodeproject.bzl", "xcode_project") xcode_project( name = "MyProject", targets = [ "//ios-app:ios-app" ], paths = [ "**" ], )
Finally, build the project with Bazel
bazel build MyProject
XCHammer also works as a standalone project generator. First build XCHammer and install to the path:
# Installs to `/usr/local/bin/` make install
Then, generate using a XCHammerConfig.
xchammer generate <configPath>
XCHammer is configured via a
yaml representation of XCHammerConfig.
The configuration describes projects that should be generated.
# Generates a project containing the target ios-app targets: - "//ios-app:ios-app" projects: "MyProject": paths: - "**"
See XCHammerConfig.swift for detailed documentation of the format.
To learn about how Pinterest uses XCHammer with Bazel locally check out Pinterest Xcode Focused Projects.
By default, XCHammer doesn't provide or enforce any build configuration defaults in Bazel or Xcode. It exposes APIs to make it possible to configure Bazel options Xcode dynamically, on a target level, on a project level, and per architecture.
When using the CLI the
is passed via an
.yml file, and when using the
xcode_project rule, the
XCHammerConfig is passed into the rule.
bazel makes it possible to select a wrapper command for Bazel.
In practice, this might be
bazelisk or a wrapper script. In the case of
XCHammer's own Xcode project, it's tools/bazelwrapper to
handle make variable substitution at build time.
The configuration option,
build_bazel_platform_options make it possible to configure architecture
specific settings for each target. Checkout
sample/UrlGet/BUILD.bazel passes a
architecture in an iOS app.
The configuration option,
build_bazel_options makes it possible, to set extra options on bazel target.
build_bazel_template makes it possible to run a script inside
of Xcode before and after building. This also allows the user to pass in Bazel
arguments at build time.
Checkout the BUILD file and samples for examples.
At the time of writing, there should be a way to build in "debug mode" in order
for LLDB to work. One possibility is to set this as a default and override when
releasing. By default, it's possible to pass variables to Bazel. For example,
in XCHammer's own Xcode project,
tools/XCHammerXcodeRunscript.sh it set's the
compilation_mode based on Xcode's
For the purpose of running static analysis, linters, and enabling other
options, it's possible to pass in extra bazel arguments at build time. For
example you might hinge running static analyzer on the analysis action in Xcode
RUN_CLANG_STATIC_ANALYZER. Bazel doesn't have a way to run linters
or static analysis so it's totally up to the user how to run this.
XCHammer provides a path to optionally integrate with Xcode's build system and progress bar.
Under Swift and clang compilers, the execution root is written into debug info in object files by default. XCHammer writes an lldbinit file to map this directory to the source root of source code, so that both breakpoints and sources work in Xcode.
To make outputs consistent and debuggable across machines, e.g. with remote
caching, it's recommended to use debug info remapping. Debug info remapping is a
technique that simply remaps absolute paths in debug info to a stable location.
LLDB then is able to map these to the source directory, via a
target.source-map. By default, these Bazel flags are not configured and
require adding additional flags to the build. Generally, these flags should set
.bazelrc for every build.
Clang provides debug info remapping via the
-fdebug-prefix-map flag. For
Objective-C, C, C++, debug info remapping is implemented at the crosstool level.
Configure Bazel to pass these arguments by setting
--copt="DEBUG_PREFIX_MAP_PWD=." or providing a custom crosstool. See setting
for more info.
Starting with Xcode 10.2, Swift provides debug info remapping via the
rules_swift supports the ability to pass the debug
--swiftcopt=-Xwrapped-swift=-debug-prefix-pwd-is-dot to remap debug
info in Swift.
XCHammer will automatically write a compatible remapping in the
HAMMER_USE_DEBUG_INFO_REMAPPING=YES via an
xcconfig. See XCHammer's BUILD
file, for an example of this.
Generating a dSYM for development is not recommended due to the performance hit, and in practice is only required for Instruments.app.
Please find more info about developing XCHammer in The XCHammer FAQ. Pull requests welcome 💖.