Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Separate objective-c indexstore units and records by objc_library #79

Merged
merged 5 commits into from
Jun 25, 2020

Conversation

amberdixon
Copy link
Collaborator

This behavior is similar to swift_library: https://github.com/bazelbuild/rules_swift/blob/master/swift/internal/derived_files.bzl#L66 (See its invocation of actions.declare_directory from _indexstore_directory.)

We observed an issue where it took a long time for index-import to remap bazel-generated indexstores. The slowdown was actually a result of the fact that all objective-c indexstores were being placed in the same .indexstore directory. When we broke them apart by objective-c library, things got considerably faster. Before these changes, it took 3 minutes to remap for a larger project, but now it takes 3 seconds.

There is an alternative approach we can take. This approach has been taken by Brentley here: MobileNativeFoundation/index-import#46 This PR is open right now, but once it lands, we can consider it, if we still see performance issues.

  1. Group index unit/record files into the same indexstore directory.
  2. Invoke index-import and have it run on parallel across units themselves, rather than indexstore directories.

…y per obj-c library. This behavior is similar to swift_library.
@@ -563,7 +563,7 @@ def apple_library(name, library_tools = {}, export_private_headers = True, names

objc_copts.append("-I.")

objc_copts.extend(("-index-store-path", "$(GENDIR)/rules_ios_apple_library_objc.indexstore"))
objc_copts.extend(("-index-store-path", "$(GENDIR)/rules_ios_objc_library_{}.indexstore".format(objc_libname)))
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

this will resolve to the same name for targets with the same name in different packages -- is that going to be an issue?

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

oh yeah :( Well, that wouldn't create any problems (after all, before we were grouping all the units in the same directory), but it is a bit confusing to someone debugging why certain unit files don't show up where we want them to.

Let me see if I can add package in here.

@amberdixon amberdixon merged commit 3892255 into master Jun 25, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants