ITADN

Support `#if BAZEL` when evaluating `Package.swift`

#2159Openbc-lee 创建于 2026-04-04
B
bc-leecommented
`rules_swift_package_manager` evaluates `Package.swift` by running SwiftPM commands such as `swift package dump-package` and `swift package describe`. Today, those manifest evaluations do not define any Bazel-specific compilation condition. That makes it difficult to use a single `Package.swift` across multiple build systems when some dependencies or manifest settings should only be visible to Bazel. Other tools already use this pattern. For example, [Tuist](https://github.com/tuist/tuist) defines a `TUIST` flag, so when `Package.swift` is interpreted by Tuist, `#if TUIST` can be used for Tuist-specific manifest logic. Bazel could follow the same approach. A practical example is a manifest that uses conditional compilation for multiple tools: ```swift #if TUIST // Tuist-specific manifest content #elseif BAZEL // Bazel-specific manifest content #else // Plain SwiftPM content #endif ``` SwiftPM supports passing manifest compilation flags via `-Xbuild-tools-swiftc` / `-Xmanifest`. If `rules_swift_package_manager` passed `-Xbuild-tools-swiftc -DBAZEL` when evaluating the manifest, users could write `#if BAZEL` blocks in `Package.swift` to include Bazel-only dependencies or settings. This would be useful during migration from another build system to Bazel, or anytime the same manifest needs to serve multiple tools with slightly different dependency graphs. ## Proposed change Pass `-Xbuild-tools-swiftc -DBAZEL` to the SwiftPM commands used by `rules_swift_package_manager` for: - manifest parsing during dependency discovery - `swift_deps_index` - `@swift_package//:resolve` and `:update` If a more general interface is preferred, this could later become a configurable manifest-define attribute. But the immediate request is built-in support for `#if BAZEL`.
0 条评论