| commit | 2f5431b321ec136625cb389019993fc1207482d7 | [log] [tgz] |
|---|---|---|
| author | nglevin <nglevin@google.com> | Mon Feb 26 10:19:52 2018 -0500 |
| committer | Jonathan Dierksen <dierksen@google.com> | Wed Feb 28 18:22:32 2018 -0500 |
| tree | 68c388a423ee0607e5d6f8145f0902c3756111cd | |
| parent | f73670659974060109c294c58a37506cfe9f33a0 [diff] |
Automated rollback of commit 6989b830b6406ec84db56043ad886db665a3abd1. *** Reason for rollback *** This change isn't necessary. On macOS, all compiled apps have their debug data spread out across all generated .o files, rather than linking it directly into the binary. The binary itself has a small debug map to point to these .o files. The .dSYM bundle pulls all the information from those .o files into a common binary structure, but this is typically assumed to be optional. https://stackoverflow.com/a/12827463 https://stackoverflow.com/a/33307778 (to a lesser extent) Meanwhile, this -g0 is ignored as it follows the '-g' to emit debug symbols. Clang's response to combining these flags is to read the '-g' first and ignore later flags related to emitting debug symbols. Because the dSYM bundle is composed directly from the generated .o files and the debug map, there is not a fantastic way to defer or mitigate that cost. Some investigation could be done of the dsymutil -minimize feature that has been in macOS for some time, and recently upstreamed in llvm-dsymutil (https://reviews.llvm.org/D42688), but that is not yet a priority. PiperOrigin-RevId: 187017593
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: