MobileNativeFoundation/rules_xcodeproj

[Incremental] Bug: products such as *.a, *.o and Mach-O are also generated in 'indexbuild_output_base' in process of index build

LLlkaiwen opened this issue · 1 comments

LLlkaiwen commented

Description

Products such as *.a, *.o and Mach-O are also generated in indexbuild_output_base in process of index build. Is it a waste of build time and disk usage ?

Reproduction steps

In project of rules_xcodeproj at tag 1.15.0.

  1. bazel run //tools:xcodeproj
  2. open tools/tools.xcodeproj
  3. wait for index build finished
  4. check products of indexbuild_output_base, such as prodcuts in directory
    */rules_xcodeproj/bazel-output-base/rules_xcodeproj.noindex/indexbuild_output_base/execroot/_main/ bazel-out/darwin_arm64-dbg-macos-arm64-min13.0-applebin_macos-ST-8cf34477628e/bin/tools/generators/xcschemes

Expected behavior

Do not generate products such as *.a, *.o and Mach-O in index build

rules_xcodeproj version

1.15.0

Xcode version

15.0

Bazel version

7.0.0

rules_apple version

No response

rules_swift version

No response

Additional information

No response

brentleyjones commented

Per the release notes, with the mention of #2859:

The targets for a scheme (e.g. .app, .xctest, .a) are now built in Index Build, similar to how Xcode does it

So .app, .xctest, .a, etc. are the primary thing built for a given target, in order to 100% correctly build the transitive dependencies of said products. This is what allows us to properly fix things like #2852.

We adjust --experimental_remote_download_regex to include the file types we care about. That means that to prevent .o files (and .a files for top-level targets) from being downloaded (if they are cached in a remote or disk cache), you can use build:rules_xcodeproj --remote_download_toplevel. To prevent .a files from being downloaded for library targets, or possibly .app bundles for top-level targets, you can use build:rules_xcodeproj_indexbuild --remote_download_minimal.

I agree this is a trade-off, but I believe it's the right one. To quote #2859:

There are four main benefits with this new way (which is good, because the above is a pretty big downside):

  • We now generate/download previously tricky to track files like vfs overlays and hmaps
  • Less Starlark CPU usage collecting all of the generated files
  • Less Starlark memory usage retaining these generated files
  • Much smaller BEP, since the output groups are smaller, resulting in less memory usage and faster builds