More than 1 swift file for the bidirectional scenario does not build

[afabri]

When adding a swift file solve.swift here in the CmakeLists.txt of the library, the generation of the bridge code fails.

FAILED: lib/fibonacci/include/fibonacci/fibonacci-swift.h /Users/geometryfactory/afabri/swift-cmake-examples/3_bidirectional_cxx_interop/build/lib/fibonacci/include/fibonacci/fibonacci-swift.h 
cd /Users/geometryfactory/afabri/swift-cmake-examples/3_bidirectional_cxx_interop/lib/fibonacci && /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/swiftc -frontend -typecheck -I/Users/geometryfactory/afabri/swift-cmake-examples/3_bidirectional_cxx_interop/include fibonacci.swift;solve.swift -sdk /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX14.4.sdk -module-name SwiftFibonacci -cxx-interoperability-mode=default -emit-clang-header-path /Users/geometryfactory/afabri/swift-cmake-examples/3_bidirectional_cxx_interop/build/lib/fibonacci/include/fibonacci/fibonacci-swift.h
<unknown>:0: error: unable to load standard library for target 'x86_64-apple-macosx14.0'

This also happens with the code of PR #9

Ideally I want the bridge code generator only getting applied on one of the swift files, and the other swift files are the backend code doing the real work. I think this might make a nice scenario for your repository.

[afabri]

I am also wondering if it made sense to distinguish between swift files where we want to make the API available and others where we don't.

[etcwilde]

error: unable to load standard library for target 'x86_64-apple-macosx14.0'

It looks like I missed the COMMAND_EXPAND_LISTS as you pointed out in #9. Adding that to the custom command should fix it.

Ideally I want the bridge code generator only getting applied on one of the swift files, and the other swift files are the backend code doing the real work.

So normally what I do for C interop is have two libraries, one that does the actual work in Swift, and one that exposes the API that I want in C. Not unlike how folks tend to expose C++ libraries through a pImpl'd facsimile API over the top of their C++ library rather than exposing the C++ directly. In think in terms of "public interface", splitting them into separate libraries probably makes sense.

One of the goals was to make that less required with C++ interop so that you could implement parts of an existing codebase in Swift without needing to do a lot of bridging work. So the idea here is that

What eventually ends up in the generated header is influenced by access level. public access will show up in the public interface, both in Swift and in the generated header. Something private won't, so you can adjust things a bit that way too.

[etcwilde]

This should be fixed as of #9. Please verify.