-
Notifications
You must be signed in to change notification settings - Fork 471
Fixes for C-level build of libdispatch on Linux #263
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
@@ -29,6 +29,8 @@ include(DispatchAppleOptions) | |||
option(ENABLE_DISPATCH_INIT_CONSTRUCTOR "enable libdispatch_init as a constructor" ON) | |||
set(USE_LIBDISPATCH_INIT_CONSTRUCTOR ${ENABLE_DISPATCH_INIT_CONSTRUCTOR}) | |||
|
|||
option(BUILD_SHARED_LIBS "build shared libraries" ON) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Do we want to default to the shared libraries first? We can, I went with the defaults of auto tools, which was static by default.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
we need the shared libraries when building to include in Swift. For me at least, autotools/libtool was defaulting to shared libs before. libtool called the linker script libdispatch.a, but what it really was building was .libs/libdisaptch.so
src/CMakeLists.txt
Outdated
set(dispatch_DTRACE_HEADERS) | ||
if(dtrace_EXECUTABLE) | ||
list(APPEND dispatch_DTRACE_HEADERS ${CMAKE_CURRENT_BINARY_DIR}/provider.h) | ||
ADD_CUSTOM_COMMAND( |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Lower case please. Can you please create a target for this? This will otherwise run constantly. I can quickly write a patch to prevent that if you like.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
not sure what you mean; the dependency seems to be working for me.
add_library(dispatch | ||
${dispatch_DTRACE_HEADERS} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Use target_sources
instead please.
@@ -90,7 +90,7 @@ function(add_unit_test name) | |||
COMMAND bsdtestharness $<TARGET_FILE:${name}>) | |||
set_tests_properties(${name} | |||
PROPERTIES | |||
TIMEOUT 30 | |||
TIMEOUT 600 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ill leave this to @das to figure out. The old timeout used to be 30s.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
right. 30 is not long enough. Swift CI machines get very loaded. I'm seeing dispatch_select routinely take 40 or 50 seconds.
@dgrove-oss what swift level changes are needed? |
For Swift, we need to add dependencies on a couple of Swift runtime libraries when linking the test exectutables. I have a patch that does that. |
Still needed pieces of PR#257 related to C-level build/test. 1. rule to generate provider.h from provider.d using dtrace 2. default to building shared libraries (needed for Swift) 3. increase test timeout to 600 seconds (for noisy Swift CI)
28821b0
to
3b20b37
Compare
sounds good, thanks. I merged the pending ones |
Still needed pieces of PR#257 related to C-level build/test.