repository·main·Indexed 43 days ago
https://github.com/bazelbuild/rules_swiftSwift Rules for Bazel provide rules to build Swift libraries, tests, and executables for macOS, Linux, and Windows. It supports all Apple platforms including iOS, tvOS, visionOS, and watchOS when used alongside Apple Rules. Key rules include `swift_library`, `swift_binary`, and `swift_library_group`. The project also provides the `BazelRunfiles` library for locating data dependencies at runtime and utilities for C/Objective-C interoperability via `create_swift_interop_info`.
The SwiftToolchainInfo provider manages how the Swift runtime is linked.
dynamic_runtime_cc_info (a CcInfo provider) to select the ordinary dynamic Swift runtime. This is used by final links unless swift.static_stdlib is enabled.static_runtime_cc_info (a CcInfo provider) to select the static Swift runtime. This is used by final links when swift.static_stdlib is enabled.When you define a toolchain with swift.toolchain(name = "<name>"), the extension generates a parent repository @<name> which exposes the following targets for each platform:
@<name>//:cc_toolchain_embedded_<platform>: The C/C++ toolchain used for the embedded Swift target platform.@<name>//:swift_toolchain_embedded_<platform>: The Swift toolchain for the embedded target.@<name>//:swift_toolchain_exec_<platform>: The Swift toolchain used as an exec toolchain (compiling tools that run on the build host).The actual extracted toolchain resides in the per-platform repository @<name>_<platform>.
The swift_overlay rule allows authors of C or Objective-C libraries to provide additional Swift-specific APIs that are automatically available when a Swift target depends on that library.
Key Characteristics:
swift_overlay target should only be referenced in the aspect_hints of a single objc_library or cc_library target.objc_library(
name = "MyModule",
srcs = ["MyModule.m"],
hdrs = ["MyModule.h"],
aspect_hints = [":MyModule_overlay"],
deps = [...],
)
swift_overlay(
name = "MyModule_overlay",
srcs = ["MyModule.swift"],
deps = [...],
)You can use an arbitrary non-protoc Swift protobuf compiler by implementing a custom rule that provides SwiftProtoCompilerInfo. This custom rule must be passed to the compilers attribute of a swift_proto_library target.
The custom rule's implementation must include a function that accepts a list of ProtoInfo providers and produces a list of Swift source files from them, which the swift_proto_library rule will then compile.
rules_swift_package_manager (maintained by cgrindel).Use the swift_library_group rule to bundle multiple Swift Bazel targets into a single dependency. This is analogous to providing multiple products in a single Swift Package Manager package. Any target that depends on the swift_library_group will have the Swift modules listed in its deps forwarded to it.
# Conceptual usage pattern
swift_library_group(
name = "Helpers",
deps = [
":TestHelpers",
":StringHelpers",
],
)When targeting WebAssembly, setting linkshared = True in swift_binary produces a "reactor" module (<name>.wasm).
This module:
_start entry point._initialize function.-Xlinker --export=<symbol> or -Wl,--export=<symbol> flags within the linkopts attribute.swift_binary(
name = "my_wasm_reactor",
srcs = ["lib.swift"],
linkshared = True,
linkopts = ["-Xlinker", "--export=my_exported_function"],
)The swift_proto_compiler rule is a new abstraction used to configure how protos are generated. It encapsulates the protoc binary, the required protoc plugin binaries (like SwiftProtobuf or grpc-swift), and the specific options passed to those plugins.
This rule is passed to the compilers attribute of a swift_proto_library target. This decoupling allows users to use custom versions of protoc or specific plugins without being tied to the internal dependencies of rules_swift.
The following providers are internal implementation details of the rules. Users should not rely on them or assume their structure is stable:
SwiftFeatureAllowlistInfo: Describes features and packages allowed to request or disable them.SwiftPackageConfigurationInfo: Describes compiler configurations applied by default to specific packages.The swift_proto_library rule does not enforce a strict mapping between proto packages and Swift modules. You have flexibility in how you organize your modules:
When using explicit modules, precompiled frameworks are compiled in the context of their own target rather than the importing target. This requires that any dependencies the framework has (including other precompiled frameworks) are explicitly defined in its BUILD file.
If you are using rules_swift_package_manager, you must manually map these dependencies in your MODULE.bazel using swift_deps.configure_package.
swift_deps.configure_package(
name = "swiftpkg_facebook_ios_sdk",
target_deps = {
"FBAEMKit": [":FBSDKCoreKit_Basics"],
"FBSDKCoreKit": [
":FBAEMKit",
":FBSDKCoreKit_Basics",
],
"FBSDKGamingServicesKit": [
":FBAEMKit",
":FBSDKCoreKit_Basics",
":FBSDKShareKit",
],
"FBSDKLoginKit": [
":FBAEMKit",
":FBSDKCoreKit_Basics",
],
"FBSDKShareKit": [
":FBAEMKit",
":FBSDKCoreKit_Basics",
":FBSDKShareKit",
],
},
)The BazelRunfiles library allows Swift binaries and tests built with Bazel to locate their data dependencies (runfiles) at runtime.
To use it:
@rules_swift//swift/runfiles to the deps of your swift_binary or swift_test rule.BazelRunfiles in your Swift code.Runfiles.create() to initialize the lookup mechanism.rlocation(_:) with the workspace-relative path to find the file URL.Runfiles.create() automatically detects whether to use a manifest-based or directory-based lookup by inspecting environment variables like RUNFILES_MANIFEST_FILE and RUNFILES_DIR. If these are not set, it attempts to locate them relative to the executable's path (argv[0]).
import BazelRunfiles
do {
let runfiles = try Runfiles.create()
let fileURL = try runfiles.rlocation("my_workspace/path/to/my/data.txt")
print("file: \(fileURL)")
} catch {
print("runfiles error: \(error)")
}