| commit | 2dc68d19b721b9be17777bd134a59dc570c39c5b | [log] [tgz] |
|---|---|---|
| author | davg <davg@google.com> | Mon Jul 16 16:26:38 2018 -0400 |
| committer | Jonathan Dierksen <dierksen@google.com> | Wed Jul 18 19:43:03 2018 -0400 |
| tree | e4f1a840071122da11f92b60fbdc383ca1fc7aec | |
| parent | 07db4900490c46d9d9c51227924fa1f71856adcf [diff] |
Keep Bazel flags consistent Whenever a Bazel configuration flag (i.e. --define, --copt) is changed/added/removed, Bazel must reanalyze the entire build graph (at least at the moment), which can be expensive. In order to avoid doing so, we must keep all of the analysis-cache-affecting flags used during the project generation phase the same as the flags used during a build inside of Xcode. There are a few keys points here: - Make sure all of our Bazel invocations set the --override_repository flag and don't change its value between builds and generation - We use different flags for Swift/non-Swift targets, so we have introduced a project-level which specifices which configuration flags to use during generation (Swift or non-Swift) - User builds (from the command line) also follow the same restrictions; in order to make it easier for the user, we now have a script located inside the generated xcodeproj which allows building of a target with the same flags that Tulsi would use. PiperOrigin-RevId: 204796256
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: