Export CMake targets for use by SwiftPM

[owenv]

This is the first pass at exporting targets so that SwiftPM can integrate Swift Build into its CMake build. It probably needs some iteration, I'll note where there are some changes I'm not certain of.

[owenv]

I'm not confident target_include_directories is the right way to be propagating module search paths to clients

[etcwilde]

When you say clients, are you referring to external projects, or to other libraries within this project?

If swift-build is intended to be linked against by other projects, you'll want to be careful about exposing absolute paths into your build directory like this, unless the project is only ever intended to be used from the build directory.

target_include_directories(SWBAndroidPlatform PUBLIC
  $<BUILD_INTERFACE:${CMAKE_CURRENT_BINARY_DIR}>
  $<INSTALL_INTERFACE: -- wherever you're installing these files to -->)

https://cmake.org/cmake/help/latest/command/target_include_directories.html#creating-relocatable-packages

[owenv]

@etcwilde thanks for taking a look! My plan was for the SwiftBuildSupport target in SwiftPM to statically link everything it uses from this repository (and eventually copy the necessary resources into its own installed resources), to mirror how the SwiftPM-based build is setup for now. Does that change your recommendation at all?

[owenv]

I'm pretty sure this is the wrong way to ensure clients of this static library end up with a libc++ linkage

[etcwilde]

Yeah, there isn't a great way to do this today. We need a mechanism to tell Swiftc to use clang++ as the clang-linker instead of clang, even when c++-interop isn't enabled. I've talked with @artemcm about it a bit, but will need something new in the driver. There are Swift runtime bits that the Swift driver knows about or I'd just say set the link language of the target to CXX, but that would break the Swift side.

[etcwilde]

When you say clients, are you referring to external projects, or to other libraries within this project?

If swift-build is intended to be linked against by other projects, you'll want to be careful about exposing absolute paths into your build directory like this, unless the project is only ever intended to be used from the build directory.

target_include_directories(SWBAndroidPlatform PUBLIC
  $<BUILD_INTERFACE:${CMAKE_CURRENT_BINARY_DIR}>
  $<INSTALL_INTERFACE: -- wherever you're installing these files to -->)

https://cmake.org/cmake/help/latest/command/target_include_directories.html#creating-relocatable-packages

[etcwilde]

Yeah, there isn't a great way to do this today. We need a mechanism to tell Swiftc to use clang++ as the clang-linker instead of clang, even when c++-interop isn't enabled. I've talked with @artemcm about it a bit, but will need something new in the driver. There are Swift runtime bits that the Swift driver knows about or I'd just say set the link language of the target to CXX, but that would break the Swift side.

[etcwilde]

There's a special version of configure_file for generating project configs:
configure_package_config_file

[owenv]

It looks like that requires specifying an install location, which I'm not sure we want here since we're just exporting static library targets for SwiftPM to link

[owenv]

Linux:

CMake Error at Sources/SWBUtil/CMakeLists.txt:107 (target_link_libraries):
  Target "SWBUtil" links to:

    Crypto::Crypto

[owenv]

@swift-ci test