Export CMake targets for use by SwiftPM #376
Conversation
owenv
requested review from
jakepetroules,
mirza-garibovic,
mhrawdon and
neonichu
as code owners
| @@ -37,3 +37,8 @@ target_link_libraries(SWBAndroidPlatform PUBLIC | |||
| SWBUtil) | |||
| target_sources(SWBAndroidPlatform PRIVATE | |||
| "${CMAKE_CURRENT_BINARY_DIR}/resource_bundle_accessor.swift") | |||
|
|
|||
| target_include_directories(SWBAndroidPlatform PUBLIC | |||
There was a problem hiding this comment.
I'm not confident target_include_directories is the right way to be propagating module search paths to clients
There was a problem hiding this comment.
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 -->)
There was a problem hiding this comment.
@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?
| @@ -16,8 +16,15 @@ target_compile_definitions(SWBCSupport PRIVATE | |||
| $<$<PLATFORM_ID:Windows>:_CRT_NONSTDC_NO_WARNINGS>) | |||
| target_compile_options(SWBCSupport PRIVATE | |||
| -fblocks) | |||
| target_link_options(SWBCSupport PUBLIC | |||
There was a problem hiding this comment.
I'm pretty sure this is the wrong way to ensure clients of this static library end up with a libc++ linkage
There was a problem hiding this comment.
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.
| @@ -37,3 +37,8 @@ target_link_libraries(SWBAndroidPlatform PUBLIC | |||
| SWBUtil) | |||
| target_sources(SWBAndroidPlatform PRIVATE | |||
| "${CMAKE_CURRENT_BINARY_DIR}/resource_bundle_accessor.swift") | |||
|
|
|||
| target_include_directories(SWBAndroidPlatform PUBLIC | |||
There was a problem hiding this comment.
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 -->)
| @@ -16,8 +16,15 @@ target_compile_definitions(SWBCSupport PRIVATE | |||
| $<$<PLATFORM_ID:Windows>:_CRT_NONSTDC_NO_WARNINGS>) | |||
| target_compile_options(SWBCSupport PRIVATE | |||
| -fblocks) | |||
| target_link_options(SWBCSupport PUBLIC | |||
There was a problem hiding this comment.
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.
| @@ -0,0 +1,9 @@ | |||
| set(SWIFTBUILD_EXPORTS_FILE ${CMAKE_CURRENT_BINARY_DIR}/SwiftBuildExports.cmake) | |||
|
|
|||
| configure_file(SwiftBuildConfig.cmake.in | |||
There was a problem hiding this comment.
There's a special version of configure_file for generating project configs:
configure_package_config_file
There was a problem hiding this comment.
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
|
Linux: |
owenv
force-pushed
the
cmake-exports
branch
4 times, most recently
from
ffaeb0a to
584a77b
Compare
owenv
force-pushed
the
cmake-exports
branch
3 times, most recently
from
aef39b0 to
b6f270e
Compare
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.