Ensures the determinism of vfsoverlay file #912
Conversation
hdrs, private_hdrs and swiftmodules of the same framework may be in different order when building with different build settings in Bazel 7. This change will ensure that the vfsoverlay file will be always the same for the same dependency graph.
| @@ -376,6 +376,12 @@ def make_vfsoverlay(ctx, hdrs, module_map, private_hdrs, has_swift, swiftmodules | |||
| vfs_parent_len = len(vfs_parent.split("/")) - 1 | |||
| vfs_prefix = _make_relative_prefix(vfs_parent_len) | |||
|
|
|||
| # Ensures the determinism of vfsoverlay file | |||
| # hdrs, private_hdrs and swiftmodules of the same framework may be in different order. | |||
| hdrs = sorted(hdrs) | |||
There was a problem hiding this comment.
I'd suggest to verify that these sort steps don't introduce a significant performance regression in the analysis phase.
There was a problem hiding this comment.
The overhead should be fine. apple_library has already sorted all srcs files. The number of hdrs, private_hdrs and swiftmodules is smaller than that of srcs, especially for swift modules.
There was a problem hiding this comment.
I wonder what kind of CI test can red green on this... sandbox mode only ensure all inputs that should be present are present in the inputs list, but nothing about ensuring no change on file content when a rebuild happens
There was a problem hiding this comment.
maybe start with adding before after in the PR desc? I am sure we can figure some CI test out in future based on the repro
hdrs, private_hdrs and swiftmodules of the same framework may be in different order when building with different build settings in Bazel 7. This change will ensure that the vfsoverlay file will be always the same for the same dependency graph.
hdrs, private_hdrs and swiftmodules of the same framework may be in different order when building with different build settings in Bazel 7. This change will ensure that the vfsoverlay file will be always the same for the same dependency graph.