Skip to content

Showcase a fix for exposing Swift types in an Objecive-C API #957

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.

Sign up for GitHub

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

Open
abdulowork wants to merge 1 commit into
base: main
Choose a base branch
from
Open

Showcase a fix for exposing Swift types in an Objecive-C API #957

Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
13 changes: 13 additions & 0 deletions Sources/SWBCore/SpecImplementations/Tools/SwiftCompiler.swift
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -1598,6 +1598,19 @@ public final class SwiftCompilerSpec : CompilerSpec, SpecIdentifierType, SwiftDi
}
}

if let target = cbc.producer.configuredTarget {
Copy link
Collaborator

@owenv owenv Dec 4, 2025

Choose a reason for hiding this comment

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

Thanks for the pr! Not every target will have a generated modulemap, and not every transitive dependency will build a module compatible with the current compilation, so I don't think we should attempt to inject module map flags here.

Generally speaking, the intent is that the PIF generated by swift-package-manager is supposed to include module map paths in the "imparted build properties" as needed for SwiftPM targets generating module maps. Then, swift-build is responsible for ensuring those imparted build properties are imposed on transitive dependents which build for the same platform. Based on your bug report it's possible either SwiftPM is failing to add the right path to the PIF, or the imparted properties exist but aren't propagated to dependents correctly (I haven't taken a detailed look yet). The former we'd want to fix in SwiftPM, the latter we'd likely want to fix in Swift Build at dependency resolution time instead of when we're constructing the Swift compilation task

Copy link
Author

@abdulowork abdulowork Dec 5, 2025

Choose a reason for hiding this comment

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

I looked at the output of swift package dump-pif and at similar information emitted with defaults write com.apple.dt.XCBuild EnableBuildDebugging -bool YES. I see that ObjcTarget has the following in impartedBuildProperties:

"guid": "PACKAGE-TARGET:ObjcTarget",
...
"OTHER_SWIFT_FLAGS": [
  "-Xcc",
  "-fmodule-map-file=$(GENERATED_MODULEMAP_DIR)/ObjcTarget.modulemap",

And the SwiftTarget doesn't have the imparted OTHER_SWIFT_FLAGS, so the transitive Swift consumer doesn't see the generated SwiftTarget.modulemap.

That still leaves me with a couple of questions: do I understand correctly that, for general Swift -> Swift compilation dependencies, SwiftPM relies on Swift Build to produce all outputs in $(BUILT_PRODUCTS_DIR) and have them picked up by a shared swiftc -I $(BUILT_PRODUCTS_DIR) search path?

If my understanding is correct, I see another possible fix for this issue being Swift Build creating $(BUILT_PRODUCTS_DIR)/SwiftTarget directory with the module.modulemap and the SwiftTarget-Swift.h. Then, from my understanding, both clang -fmodules and swiftc can pick the necessary Clang module, and wouldn't need to rely on the imparted build settings at all.

Would such a fix be acceptable, and would it need to be implemented in Swift Build?

Copy link
Author

@abdulowork abdulowork Dec 5, 2025 •
edited
Loading

Choose a reason for hiding this comment

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

I think the benefit of such a solution might be that if there is no Swift Producer -> ObjC Consumer dependency, then the build system doesn't need to ask the compiler to generate the -Swift.h file, and it doesn't need to create the modulemap, but if such an edge does occur, then in the case of Swift Producer -> ObjC -> Swift Consumer the Swift Consumer will still be able to see everything due to emitted module and the header in the shared search path.

Or is this something SwiftPM must decide on ahead of time based on its knowledge about the dependency graph?

Copy link
Author

@abdulowork abdulowork Dec 5, 2025

Choose a reason for hiding this comment

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

I browsed some more through the PIF files, and I see the MODULEMAP_FILE_CONTENTS, MODULEMAP_PATH, SWIFT_OBJC_INTERFACE_HEADER_DIR and SWIFT_OBJC_INTERFACE_HEADER_NAME build settings there, which I assume get encoded into PIF from here. So perhaps for the fix with the shared search path, this would still require a change in SwiftPM and not in Swift Build

let depScopes = cbc.producer.targetSwiftDependencyScopes(for: target, arch: cbc.scope.evaluate(BuiltinMacros.CURRENT_ARCH), variant: cbc.scope.evaluate(BuiltinMacros.CURRENT_VARIANT))
for scope in depScopes {
let moduleName = scope.evaluate(BuiltinMacros.PRODUCT_MODULE_NAME)
// From CoreBuildSystem.xcspec: $(OBJROOT)/GeneratedModuleMaps$(EFFECTIVE_PLATFORM_NAME)
let objroot = scope.evaluate(BuiltinMacros.OBJROOT).str
let moduleMapDir = "\(objroot)/GeneratedModuleMaps\(scope.evaluate(BuiltinMacros.EFFECTIVE_PLATFORM_NAME))"
// Doesn't work for SwiftPM targets
// let moduleMapDir = scope.evaluate(BuiltinMacros.GENERATED_MODULEMAP_DIR)
args.append(contentsOf: ["-Xcc", "-fmodule-map-file=\(moduleMapDir)/\(moduleName).modulemap"])
}
}

// Add -F for the effective framework search paths.
let frameworkSearchPaths = GCCCompatibleCompilerSpecSupport.frameworkSearchPathArguments(cbc.producer, cbc.scope, asSeparateArguments: true)
args += frameworkSearchPaths.searchPathArguments(for: self, scope: cbc.scope)
Expand Down