Hello, I am trying to build two libraries which share common code, preferably having a subfolder with the shared code and another with the code that is target specific.
I was looking for something like the following, but the syntax seems to make it so you can only have one path.
let package = Package(
path: ["Sources/Common", "Sources/ACore"] // NOT VALID SYNTAX, what I was looking to do
path: ["Sources/Common", "Sources/BCore"] // NOT VALID SYNTAX, what I was looking to do
Also, when I try to do something like this I get "has sources overlapping sources" as the error message. I could put the common code in a "CommonCore" library but then I have lots of modules and this may have performance implications. Is the common library approach the recommended way of doing this? Using a common library means that now users of the library must use a different module for the shared code. So they would have to import ACore and import CommonCore. This is undesirable.
Having a "Common" target that both "ACore" and "BCore" depend on is what you want in this case. SwiftPM doesn't let you share source files like this to avoid the potential of someone importing both "ACore" and "BCore" and having duplicate symbols.
If they are Swift yes! But SwiftPM can also build C, C++, Objective-C and Objective-C++ all of which don’t have the same benefits of module namespacing (well they use clang modules but the languages don’t differentiate them on those).
So they opted into a more consistent build structuring for all the targets. There are almost certainly other reasons as well but we would need input from someone like @Aciid to know any of those reasons.
@_exported import aims to solve this. It is underscored because it isn’t finished yet, but it already works for this use case. Be wary that its syntax may change with any update. But since its effect is only at compile time, you don’t have to worry about system updates breaking pre‐existing binaries. (And the App Store cannot tell whether you used it or not.)
Interesting! Was not aware of this, is there a commitment to support a feature like this? I don't want to use this and have it taken away. I am fine with changing syntax but worry about support being dropped later.