Only move indexstores generated by build#78
Conversation
| do | ||
| if [ -d $i ] | ||
| then | ||
| EXISTING_INDEXSTORES+=($i) |
There was a problem hiding this comment.
For simpler projects (like the ones in this repo), no unit files and no indexstore directory will be generated. In that case, we shouldn't try to move non-existent directories!
There was a problem hiding this comment.
For simpler projects (like the ones in this repo), no unit files and no indexstore directory will be generated
If that's the case, can you please add a new project that will exercise this code path?
There was a problem hiding this comment.
I realize now that the unit files were not being generated because sandboxing was enabled. Bazel would build the outputs and then delete any other files left behind (including the generated indexstores.)
For now, if anyone would like to manually test index generation in the rules_ios repo, just make sure to disable sandboxing by adding these lines to .bazelrc:
build --genrule_strategy=standalone
build --spawn_strategy=standalone
| set -euxo pipefail | ||
|
|
||
| $BAZEL_PATH build $1 2>&1 | $BAZEL_OUTPUT_PROCESSOR | ||
| $BAZEL_PATH build --build_event_text_file=$bazel_build_event_text_filename --build_event_publish_all_actions $1 2>&1 | $BAZEL_OUTPUT_PROCESSOR |
There was a problem hiding this comment.
I considered having the output-processor read from the bazel build event text file instead. But then I realized that we want to show error messages in the output as they appear, rather than waiting until the build is finished.
segiddins
left a comment
segiddins
left a comment
There was a problem hiding this comment.
What is the performance impact of this change on a large project? How does it compare to MobileNativeFoundation/index-import#46 ?
rules/xcodeproj.bzl
Outdated
| set -euxo pipefail | ||
| cd $BAZEL_WORKSPACE_ROOT | ||
|
|
||
| export bazel_build_event_text_filename=$(mktemp -d)/build_event.txt |
There was a problem hiding this comment.
since this is exported as an env var, capitalize?
There was a problem hiding this comment.
also, should the tmp dir be cleaned up after the installer gets run? Does it make sense to instead use one of Xcode's managed tmp dirs?
There was a problem hiding this comment.
Well, this file is not very large and I do sometimes look at it after the build is over. I would prefer to keep it around.
Could you clarify what you mean by one of "xcode's managed tmp dirs"? I'm not sure if I've heard of this before.
There was a problem hiding this comment.
Something like https://pewpewthespells.com/blog/buildsettings.html#derived_file_dir, or one of the other TEMP directories documented on that page
| | xargs -0 "$BAZEL_INSTALLERS_DIR/_indexstore.sh" | ||
|
|
||
| echo "Finish remapping index files" No newline at end of file | ||
| echo "Start remapping index files at `date`" |
There was a problem hiding this comment.
I put that in here intentionally, because it made it easy for me to look inside the bazel-xcode-diagnostics directory to see if my index remapping was in progress.
| do | ||
| if [ -d $i ] | ||
| then | ||
| EXISTING_INDEXSTORES+=($i) |
There was a problem hiding this comment.
For simpler projects (like the ones in this repo), no unit files and no indexstore directory will be generated
If that's the case, can you please add a new project that will exercise this code path?
...cos/xcodeproj/Single-Application-Project-AllTargets.xcodeproj/bazelinstallers/indexstores.sh
Show resolved
Hide resolved
I tried this on a larger project within Square. When I did a clean build, 111 indexstores were generated and remapped in 2 seconds. On incremental builds where no source files are changed, 0 indexstores are moved. For some reason, the objc indexstore didn't always get generated however, and that is likely the largest one. |
2 participants
Use BEP to determine which indexstore paths were generated by the compilation steps of the build. Only move those over, so we don't move every generated indexstore. This was a suggestion from other engineers at ios-dev-at-scale to make index remapping more efficient.