The update that you posted seems like a reasonable workaround, though I wonder why the MyOtherCxxTarget
is not defined (did you create the module definition?).
Up until now, I've been leaving it up to Swift/SwiftPM to autogenerate all of the module.modulemap
files (which it does by default), so I've been able to get away with creating zero module.modulemap
files for all/any targets.
However, after running into the error above when building with .cxx20
on Windows, it appears to only work if I explicitly set requires [TargetDependency]
, regardless if the module definition exists or not.
This is made obvious by the fact that Swift/SwiftPM's automatically generated module.modulemap
module definitions did nothing to sort out the error, due to the notable lacking requires [TargetDependency]
in its generated module.modulemap
files, which now appears to be required for any target dependency headers to successfully include at all (I've just gone through and added ~100 or so module.modulemap
files to every single one of my SwiftPM targets specifically ensuring that all target dependencies have a respective requires [TargetDependency]
field specified across all of my libraries
).
Personally, I don't have a preference either way if we must now manually create module.modulemap
files for all SwiftPM targets with explicit requires [TargetDependency]
entries for each SwiftPM target's respective dependencies, but if this is the case, I believe it would probably be best if SwiftPM stopped attempting to generate each of the module.modulemap
files and this gets documented in the Swift/C++ Interop Documentation.
However, with edge cases such as these:
dependencies: [
.target(name: "PyBind11", condition: .when(platforms: Arch.OS.nix.platform))
]
There is no way to conditionally requires [TargetDependency]
in the module.modulemap
files (at least that I'm aware of), so I think it may be best if SwiftPM's auto-generation of the module.modulemap
files handles this internally.
I'm not yet sure if this is Windows specific or if macOS and Linux experience this issue as well, this is my first time flipping the C++ standard to anything beyond .cxx17
.