Xcode assumes absolute paths for everything, which makes it particularly inflexible for distributed and portable builds.
Bazel makes use of relative paths from a single execution root, meaning it may embed relative paths (not absolute paths) into binaries. This is a problem with debugging with Xcode: Xcode runs lldb from the
/ directory instead of execution root, meaning these relative paths can not be resolved. Thus, we need workarounds to remap the paths.
In lldb, there are two main ways to remap source paths for a binary:
target.source-map: Remap paths at the target level, we can set this globally for Xcode but it will apply to all projects
DBGSourcePathRemapping: Remap paths at the module (dSYM) level
Problem: Remapping paths without dSYMs as dSYMs are costly in terms of time
dSYM remappings work incredibly well - for this reason, Bazel's Xcode integration currently requires dSYMs for Swift. However, they come at a major cost for incremental builds - linking together all debug information is expensive. For this reason I've been looking into no longer requiring dSYMs for Swift, but now I'm running into a problem that
target.source-map can't solve.
For Bazel, these paths are relative, so by default lldb will not be able to find them since Xcode runs lldb from
target.source-map can't apply here as only a module is given to
SwiftASTContext, not a target. And I'm trying to move away from requiring dSYMs, so that remapping option isn't here.
I'm not quite sure how to deal with this, any ideas? @Adrian_Prantl
- Some equivalent
target.source-maplldb setting for modules
- Some equivalent to dSYM files that only contain remapping (is an empty dSYM file valid?)