| commit | 3b7a1bf2b2cace33fc31d25d2fa567a4b5f4359e | [log] [tgz] |
|---|---|---|
| author | David Goldman <davg@google.com> | Wed Oct 11 14:22:57 2017 +0000 |
| committer | David Goldman <davg@google.com> | Thu Oct 12 22:07:03 2017 +0000 |
| tree | 0475ba518b9bd5822f0dbf9bedc237750e706165 | |
| parent | 3423e56f7dda31a65b4c72872c2ea4a82a413939 [diff] |
Multi-configuration indexer target support
This change allows libraries which target
multiple (Platform SDK, min OS) pairs to
reference multiple indexer targets. For
example, an objc_library shared between
an ios_application and watchos_extension
will now generate an indexer target for
iOS and watchOS. Similarly, an
objc_library depended on by an
ios_application with a minimum_os_version
of 9.0 and by an ios_unit_test with a
minimum_os_version of 8.0 will generate
two indexer targets, one for iOS 8 and
another for iOS 9.
- Swap over ruleEntryMap dictionary to a
separate class which manages the entries
in order to allow for multiple rule
entries with the same BuildLabel
(before this CL RuleEntries with the
same BuildLabel would collide and only
the last one would remain).
- Fix up the tests to run properly with
these changes. More tests to verify
this support will be added in another
CL.
- In order for Tulsi to be able to
connect the dots for multiple platforms,
a RuleEntry's deps must either have the
same configuration or only have one
RuleEntry with the given BuildLabel.
In the case that we cannot resolve
which one to use, we default back to
our current behavior of using the
last RuleEntry read. In the future,
it may be best to consider an
alternative which keeps track of
which RuleEntries have already
been used (this could be used as a
factor when deciding what to default to).
- As a side effect of this, building
objc_library and swift_library
at the top-level now generates
warnings as they are not officially
supported due to their side effects
of introducing "default" configurations
which in most cases don't build properly.
--
PiperOrigin-RevId: 171818784
MOS_MIGRATED_REVID=171818784
Open src/Tulsi.xcodeproj, and within Xcode, build the TulsiApp.
Run the TulsiApp.
Tulsi-generated Xcode projects use Bazel to build, rather than Xcode. This means that many common components of an Xcode project are handled differently than you may be used to. For example, the Info.plist file is governed entirely by BUILD rules in Bazel and is not displayed in the Xcode UI. It also means that changes made to your BUILD files, such as adding new library dependencies, are incorporated automatically when building your generated project. The only time you need to re-run Tulsi is if you want to add additional build targets or have new source files show up in Xcode for editing.