Build both shared and static libraries when ENABLE_SWIFT is ON #393
Conversation
|
this is great! CC'ing @tkremenek and @das as the Swift overall and Dispatch release managers for 4.2. I'd like to get this into 4.2.1 because it's clearly a regression from 4.1 that should be fixed ASAP. |
|
@swift-ci please test |
|
The sourcekitd compilation error is fixed with the change proposed here: swiftlang/swift#19640 |
|
So then we should wait for swiftlang/swift#19640 <swiftlang/swift#19640> to merge before proceeding with this change, correct?
… On Oct 1, 2018, at 11:23 AM, Kevin Sweeney ***@***.***> wrote:
The sourcekitd compilation error is fixed with the change proposed here: swiftlang/swift#19640 <swiftlang/swift#19640>
—
You are receiving this because you were assigned.
Reply to this email directly, view it on GitHub <#393 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AYFzK_UIBYkxOc_J6GHd-58B8id5xUUqks5ugl2KgaJpZM4XCTYN>.
|
| @@ -72,6 +72,7 @@ if(ENABLE_SWIFT) | |||
| ${SWIFT_RUNTIME_LIBDIR}/${CMAKE_SHARED_LIBRARY_PREFIX}swiftSwiftOnoneSupport${CMAKE_SHARED_LIBRARY_SUFFIX}) | |||
|
|
|||
| set(INSTALL_TARGET_DIR "${INSTALL_LIBDIR}/swift/${SWIFT_OS}" CACHE PATH "Path where the libraries will be installed") | |||
| set(INSTALL_STATIC_TARGET_DIR "${INSTALL_LIBDIR}/swift_static/${SWIFT_OS}" CACHE PATH "Path where the static libraries will be installed") | |||
There was a problem hiding this comment.
To be honest, I'm not sure I understand the point of these two cached variables. They are part of the resource dir naming scheme for the compiler, so why not always compose them when used?
| set(dispatch_targets dispatch dispatch_static dispatch_objects) | ||
| else() | ||
| set(dispatch_targets dispatch) | ||
| endif() |
There was a problem hiding this comment.
I'll fix this up in my next patch
| LIBRARY_OUTPUT_DIRECTORY ${CMAKE_BINARY_DIR}/lib/swift/${SWIFT_OS} | ||
| ARCHIVE_OUTPUT_DIRECTORY ${CMAKE_BINARY_DIR}/lib/swift/${SWIFT_OS} | ||
| ) | ||
| add_library(dispatch_static STATIC $<TARGET_OBJECTS:dispatch_objects>) |
There was a problem hiding this comment.
This breaks for windows. Please do a combined build for Windows. We need to build the objects twice, using the same objects will not work.
There was a problem hiding this comment.
I don't have a Windows machine to test on, can you elaborate on this? Are object libraries just broken in general? On Linux I could instead create a static library (with -fPIC) and then create a .so out of it with ld --whole-archive but that's not portable. Is there any way I can avoid building the objects twice on platforms where that's not required?
There was a problem hiding this comment.
No, object libraries are fine, just as long as they are built for the final type (e.g. built with knowledge that they will be used for a shared library or not). The best way to accomplish this is to perform two builds with the right CMake flags so that you build the objects the right way.
|
#395 actually will unconditionally build the shared and static versions of BlocksRuntime now. That should be sufficient for your needs right? |
Fixes: https://bugs.swift.org/browse/SR-7085
https://bugs.swift.org/browse/SR-7039
https://bugs.swift.org/browse/SR-8854