If in Package.swift if I configure Target1 to use Sources/Target1 and Sources/Shared, and Target2 to use Sources/Target2 and Sources/Shared, I get an error that the same source is present in 2 different targets, and thus I can't generate an Xcode project.
Is there any reason for this limitation? I can understand that the ideal setup would be to create a new Shared target and make that as a dependency of Target1 and Target2, but sadly the Shared code is generated, and it doesn't include the appropriate visibility modifiers for the classes to be accessible by dependents.
My workaround is generating the files into each of Target1 and Target2, but this is obviously way dirtier than sharing the sources between multiple targets.
Why is that a bad thing? Is it to prevent prevent people from shooting themselves in the foot because it could lead to duplicate symbol errors if not done correctly?
Yeah, it can create different types of build issues. You can end up mixing Swift and C sources which SwiftPM can't even handle, or it can lead to duplicate symbols if you mix two C targets and try to form a product with those targets, or the target dependencies (imports/includes) may not be available in one of the target.
Just to note this caused us an issue too. We needed to compile the same source twice with different Swift flags. Using symlinks causes problems with saving etc in Xcode my colleague informs me.
There's also the option to exclude specific files or directories. This was useful in a project with Objective-C and Swift where I was able to exclude the Swift files. This isn't your exact use case but should work the same. :)
While in my specific case, this may work-- as there are few files that differ across platforms. If I have a larger project, with many shared files and many non-shared files, this approach seems limiting. It seems natural that SPM would provide a way to share files across targets. It seems a common use case.