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

Fix apple_library rule not working in sandbox when do SwiftCompile in mixed sources #894

Merged
merged 1 commit into from
Aug 19, 2024

Conversation

gyfelton
Copy link
Contributor

@gyfelton gyfelton commented Aug 16, 2024

To repro, run bazel clean; bazel build //tests/ios/frameworks/mixed-source/only-source:SwiftLibrary -s --sandbox_debug --strategy=SwiftCompile=sandboxed and got
<unknown>:0: error: underlying Objective-C module 'SwiftLibrary' not found error

usingbazel aquery //tests/ios/frameworks/mixed-source/only-source:SwiftLibrary_swift to look at input list, realized bazel-out/darwin_arm64-dbg/bin/tests/ios/frameworks/mixed-source/only-source/SwiftLibrary-modulemap/SwiftLibrary.modulemap entry is not there even though that's sth generated by the module_map generator

So adding this fixed the issue because sandbox can now pick up this file

Next step: setup CI job here that run everything in sandbox mode, try to fix anything that is broken in another PR

@gyfelton gyfelton changed the title Fix apple_library rule not working in sandbox when do SwiftCompile in mixed sources Fix apple_library rule not working in sandbox when do SwiftCompile in mixed sources Aug 16, 2024
@gyfelton gyfelton requested a review from congt August 16, 2024 21:21
@@ -940,8 +941,8 @@ def apple_library(
"@build_bazel_rules_ios//:swift_disable_import_underlying_module": [],
"//conditions:default": ["-import-underlying-module"] if not feature_names.swift_disable_import_underlying_module in features else [],
})
swiftc_inputs += [module_map]
Copy link
Collaborator

@luispadron luispadron Aug 16, 2024

Choose a reason for hiding this comment

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

Doesnt this already get added for the extended modulemap below? Or is that overridden 👀

Copy link
Contributor

@congt congt Aug 16, 2024

Choose a reason for hiding this comment

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

This module_map is passed to framework_vfs_overlay_name_swift, while the extended modulemap below is different and passed to framework_vfs_overlay_name and objc_libname. I think it's unnecessary to add the extended modulemap to swiftc_inputs.

(BTW, the code is really hard to reason. We need to clean it up)

Copy link
Contributor

Choose a reason for hiding this comment

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

@gyfelton Could you test deleting line 965 to see if it still works as expected?

Copy link
Collaborator

Choose a reason for hiding this comment

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

Yeah agreed on it being hard to reason about. I'm happy to merge whatever has the least amount of changes, thinking about it more im not sure extended module map should be an input so let's try deleting it.

It might be best to create a sandbox test ci job and merge these together

Copy link
Contributor Author

@gyfelton gyfelton Aug 19, 2024

Choose a reason for hiding this comment

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

So the extended modulemap has two major diff:

  1. location: the added module map has umbrella header next to it, but the extended one is at root
Screenshot 2024-08-19 at 9 43 48 AM
  1. content:
    extended one has the following:
framework module SwiftLibrary {
    umbrella header "SwiftLibrary-umbrella.h"

    export *
    module * { export * }
}

module SwiftLibrary.Swift {
    header "SwiftLibrary-Swift.h"
    requires objc
}

The SwiftLibrary.Swift module is the net addition to the original module map

deleting the adding of extended module map works for my case but i am not sure about the implication of removing it.
I will add a TODO here for now and if we all agree on the future plan, i can come back to this esp. during the time when i need to have rules_ios to fully pass CI in sandbox. WDYT?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

strike that, that is needed or we got -swift.h file not found error in our repo's compilation

Copy link
Contributor

Choose a reason for hiding this comment

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

that is needed or we got -swift.h file not found error in our repo's compilation

Yes, we still need the extended modulemap for framework_vfs_overlay_name and objc_libname, but I don't think we need to add it to swiftc_inputs on line 967 because the swift compilation shouldn't need the umbrella header or -Swift.h.

@gyfelton gyfelton force-pushed the gyfelton/fix-library-sandboxed branch from 4ca032a to 2a88b70 Compare August 19, 2024 13:51
@gyfelton gyfelton enabled auto-merge (squash) August 19, 2024 13:51
@gyfelton gyfelton merged commit 7b16cda into master Aug 19, 2024
9 checks passed
@gyfelton gyfelton deleted the gyfelton/fix-library-sandboxed branch August 19, 2024 14:35
@@ -952,6 +953,8 @@ def apple_library(
generated_swift_header_name = module_name + "-Swift.h"

if module_map:
# TODO: now that we always add module_map as a swiftc_input,
Copy link
Contributor

Choose a reason for hiding this comment

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

We should move the TODO to line 967.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

yup removing in my next PR trying to get CI sandbox run

gyfelton added a commit that referenced this pull request Aug 20, 2024
What changed:
1. Add sandbox on/off to testing matrix, so we have 2 bazel version *
VFS on/off * sandbox on off = 8 tests in total ATM
2. Fix redefinition of `AppErrorCode` enum error in sandbox mode by
removing the extra import in bridging header. The tests still works and
can catch renaming of the enum for example. Why it was working in non
sandbox mode is unknown
3. Add `sandbox` config to include all settings needed to pass CI.
specifically allow a small set of actions to run locally.

Why this change:
To add CI coverage to sandbox mode to ensure no regression on it, now
that we have fixed issues with sandbox mode in
#894

Discussion:
CI duration might be a concern, we can exclude certain combo in the test
matrix if we want, it's possible with `exclude` keyword
luispadron added a commit that referenced this pull request Aug 21, 2024
The normal modulemap was added in
#894 and the extended
modulemap is only for the objective-c part of the library so we
shouldn't add it for the swiftc_inputs
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.

3 participants