I'm writing some software on Linux and using Swift Package Manager 6.2 where I have two things:
Project A is a library with C, C++, and Swift code, let's say the Package.swift targets are:
TC, TCpp and TS (which depends on TC and TCpp).
Project B is an application that uses Project A's library but there are problems.
Problems:
Project B can only see TC's symbols when I add an explicit "import TC", in addition to the existing "import TS". I would prefer to have only one import for the entire library.
Project B cannot link because the compiler cannot find TCpp's code in the .o files but looking in .build I find the .o definitely has all the C++ compiled code in it.
Are these known issues of SPM 6.2?
My attempts at getting this resolved by using LLMs has led to nothing very useful. They keep suggest invalid Package.swift syntax. I guess they are not trained on using the latest package manager behaviors on Linux.
I believe this is a known issue using Swift 6.2. Starting Swift 6.4, the SwiftPM's default build system is "Swift Build", which is the same build engine used by Xcode. It should be easier to support multi-language targets, though it may require some work in SwiftPM for proper support.
For 1, you can use @_exported import OtherLib in MyLib in one file and that'll export the whole API of OtherLib for users of MyLib.
This attribute is underscored but it's been stable for years so it should be fine. To be honest I'm not sure why it hasn't graduated to not-underscored yet.
I'm glad you are got it partially working, but, for what it's worth, there are 6.4 development snapshots you can use, so there is no need to build the compiler yourself ;)
I actually got it fully working with 6.2.4, but I'm not entirely sure why it works.
One thing that I did that I'm not entirely sure about is, I had to use some hard links to ensure that C and C++ code could access the same C header files. For some reason, without doing that the C++ code couldn't see the C shim headers.
I've also seen cases where the linker can't find C functions that were called from Swift.
Of course, whenever I build I do a swift package clean first and delete the Package.resolved and .build, to start each build with a clean slate.