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

Add rules for building SDK frameworks for explicit module compilation #562

Draft
wants to merge 55 commits into
base: master
Choose a base branch
from

Conversation

dierksen
Copy link
Contributor

No description provided.

Copy link
Contributor

@thiagohmcruz thiagohmcruz left a comment

Choose a reason for hiding this comment

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

Just a few questions/nits for now! Can take a second pass once it's ready for review

Copy link
Contributor

@jerrymarino jerrymarino left a comment

Choose a reason for hiding this comment

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

@dierksen Nice - the comments I've got are mostly minor - if we want to iterate on this incrementally in smaller bits that seems fine 👍

.vscode/settings.json Outdated Show resolved Hide resolved
tools/toolchains/xcode_configure/xcode_configure.bzl Outdated Show resolved Hide resolved
tools/toolchains/xcode_configure/xcode_configure.bzl Outdated Show resolved Hide resolved
tools/toolchains/xcode_configure/xcode_sdk_frameworks.bzl Outdated Show resolved Hide resolved
tools/toolchains/xcode_configure/xcode_sdk_frameworks.bzl Outdated Show resolved Hide resolved
* master:
  Forward testonly attribute for all rules (bazel-ios#573)
  Run buildifier fix, clean up unused variables/functions (bazel-ios#572)
  Add discussion bullet points to README (bazel-ios#565)
  Fixing git_repository assumption in xcbuildkit dep (bazel-ios#566)
* framework_repo_rule:
  Forward testonly attribute for all rules (bazel-ios#573)
  Run buildifier fix, clean up unused variables/functions (bazel-ios#572)
  Add discussion bullet points to README (bazel-ios#565)
  Fixing git_repository assumption in xcbuildkit dep (bazel-ios#566)
@dierksen
Copy link
Contributor Author

Lots of stuff still to revert here, but overall the repo rule is about finished.

The biggest issue I'm working through at the moment is XCTest, which doesn't work with swift_c_module, so I'll probably need to put together a simple objc_library-esque rule and/or create a separate new_external_repository to pull that in.

* master:
  Bump Xcode, macos image, bazel, and carthage versions (bazel-ios#580)
  Make the wrap_resources_in_filegroup rule name morre unique (bazel-ios#592)
  Add ability to configure build service (bazel-ios#577)
  Updating rules_apple to point to the latest on the bazel/5.x branch (bazel-ios#589)
* master:
  Revert "Bump xchammer and xcbuildkit (bazel-ios#597)" (bazel-ios#599)
  Bump xchammer and xcbuildkit (bazel-ios#597)
  Increase bazel server startup timeout (bazel-ios#596)
  Fix issue merging xcconfig values that are lists (bazel-ios#590)
  Remove INFOPLIST_FILE setting from the legacy xcodeproj rule (bazel-ios#593)
* master:
  Add SwiftInfo to hmap/vfs rules to suppress module map generation (bazel-ios#603)
  Bump rules_apple, rules_swift, and stardoc (bazel-ios#604)
  Update xcconfig merging to override keys (bazel-ios#602)
  Explicitly unset the plist value, so XcodeGen doesn't go searching for one (bazel-ios#601)
  Bump xchammer and xcbuildkit (2) (bazel-ios#600)
@dierksen
Copy link
Contributor Author

Happy 2-month birthday to this PR 🎂

Remaining issues that I'm pondering:

  • still not completely sure on -import-underlying-module: I don't completely understand the behavior for this flag, and it seems weirdly inconsistent between mixed-module and swift-only libraries
  • need to mark sdk frameworks as extension-safe (assuming all of them are? I really don't know)
  • all of the xchammer--namespaced libraries need the frameworks added

@@ -975,7 +975,7 @@ def apple_library(name, library_tools = {}, export_private_headers = True, names
deps = deps + private_deps + lib_names + select({
"@build_bazel_rules_ios//:virtualize_frameworks": [framework_vfs_overlay_name_swift],
"//conditions:default": [framework_vfs_overlay_name_swift] if enable_framework_vfs else [],
}),
}) + (["@xcode_sdk_frameworks//:XCTest"] if testonly else []),
Copy link
Contributor

Choose a reason for hiding this comment

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

Why does this need to link XCTest to all compile actions? I think if the user includes XCTest in the sdk_frameworks it'd only need it then.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

sdk_frameworks only affects linking and it's only on objc_* AFAICT.

Copy link
Contributor

Choose a reason for hiding this comment

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

Yeah today it's used for linking. However, the users already give us the SDK frameworks via sdk_frameworks so I imaged we might need / want to leverage that API for explicit PCMs

Without such a switch it looks like the PR has to injects every SDK to the swift compile action? I imagined that wouldn't be ideal from a performance angle but will have to dig into it a bit more.

@@ -561,7 +561,7 @@ def apple_library(name, library_tools = {}, export_private_headers = True, names
tags_manual = tags if "manual" in tags else tags + _MANUAL
platforms = kwargs.pop("platforms", None)
private_deps = [] + kwargs.pop("private_deps", [])
lib_names = []
lib_names = ["@xcode_sdk_frameworks"]
Copy link
Contributor

Choose a reason for hiding this comment

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

I'd suggest to make this a feature that flips it on and any of the other rules_swift features that it currently uses, so they can set apple.explicit_module_compilation and it adds the relevant deps

-//tests/macos/xcconfig:used_as_condition_xcconfig

# `deleted_packages` is needed below in order to override the value of the .bazelrc file
EXPLICIT_MODULES=1 bazelisk test --local_test_jobs=1 --apple_platform_type=ios --deleted_packages='' -- \
Copy link
Contributor

Choose a reason for hiding this comment

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

Does this need to have the arguments as it does above?

overrides = overrides,
)

repository_ctx.symlink(
Copy link
Contributor

Choose a reason for hiding this comment

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

Would you add a comment about why this symlinks in XCTest here?

}})
)

alias(
Copy link
Contributor

Choose a reason for hiding this comment

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

Similar to other bits on XCTest special casing

run: |
# Host config
EXPLICIT_MODULES=1 bazelisk test --local_test_jobs=1 \
--features=swift.use_c_modules \
Copy link
Contributor

Choose a reason for hiding this comment

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

Can rules_ios turn on the dependent rules_swift features when it sets expilict module compilation enabled?

congt added a commit that referenced this pull request Aug 21, 2024
### What
It scans and configures all SDK frameworks which are required for
explicit module builds.

Specifically, it 1) uses the bazel_tools//tools/osx:xcode_configure.bzl
to fetch all local Xcode infos,
  2) finds all frameworks under the xcode SDK path,
and 3) uses the swiftc -scan-dependencies mode to fetch the dependency
graph among all Swift and Clang SDK modules.

We use swift_module_alias to represent a Swift SDK module and
sdk_clang_module for a Clang SDK module.

This PR is based on the previous attempt to support SDK frameworks:
#562

### Test 

Runs `bazel build --config=explicit_modules --nobuild
@xcode_sdk_frameworks//...` and inspects the generated repository at
`$(bazel info
output_base)/external/_main~xcode_sdk_frameworks~xcode_sdk_frameworks`.


### Next steps:
The dependency among swift_module_alias and sdk_clang_module doesn't
work yet. We need to fix that.
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.

4 participants