commit | c9816abb7039e7f98494bc8b1e377a9fdc94a7d4 | [log] [tgz] |
---|---|---|
author | nglevin <nglevin@google.com> | Tue Mar 13 17:37:32 2018 -0400 |
committer | David Goldman <davg@google.com> | Wed Mar 14 18:30:16 2018 -0400 |
tree | e4ade2208a3ee4facff6cb122b812e19f2dbea9c | |
parent | 4df969541369780dbada4a6e4ec7944bce75839b [diff] |
Adding DBGShellCommands interactions to Tulsi. This serves as a replacement for Spotlight in finding debug symbols, as a primary source with Spotlight as a fallback. In instances when the Spotlight service cannot be relied upon to find dSYM bundles, or when Spotlight takes too long to index a new dSYM UUID, we instead use a SQLite database using the API recommended by Apple to reference locations to those dSYM bundles by architecture. Lookups are done by a small C program, for maximum efficiency. All other interactions with the database are handled by Python scripts, including managing the schema. Database is cleaned of references to dSYMs that cannot be found during project generation. This feature can be turned off through the Tulsi GUI, in the Shared Options tab, on a per-Tulsi project basis. Requires an Xcode.app restart to acknowledge new DBGShellCommands settings. This goes for all changes to com.apple.DebugSymbols. https://lldb.llvm.org/symbols.html for more information. As we now have a means to find dSYMs in addition to Spotlight, the Spotlight requirement checks have been removed as well. PiperOrigin-RevId: 188931719
Open src/Tulsi.xcodeproj, and within Xcode, build the TulsiApp.
Run the TulsiApp.
Tulsi-generated Xcode projects use Bazel to build, not Xcode via xcbuild. This means that many common components of an Xcode project are handled differently than you may be used to. Notable differences: