build: allow system-supplied libBlocksRuntime on systems other than Darwin #534
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
In the past, the GNUstep project has used the ability so link (a fairly ancient version of) libdispatch against a custom libBlocksRuntime in order to ensure interoperability with its Objective-C runtime (which bundles a BlocksRuntime implementation). It seems that this facility was removed in PR #396 in favour of a check on whether it's building for Darwin to decide whether the in-tree version should be built.
That seems accidental, given the stated purpose of that PR, so I would very much like to re-add that facility. I have now done this by re-adding the elided
find_package(BlocksRuntime QUIET)
statement and deciding whether to build the in-tree version depending onBlocksRuntime_FOUND
(also the same as prior to PR #396). I hope this is what's intended here. I've checked that this works on a Linux system both with and without a custom libBlocksRuntime.Unfortunately, I couldn't convince libdispatch to build on my macOS machine – either with or without this change, so that is probably due to my lack of expertise. But it could very well be possible that building the in-tree libBlocksRuntime needs to be conditional on
NOT (CMAKE_SYSTEM_NAME STREQUAL Darwin OR BlocksRuntime_FOUND)
.Additionally, yet relatedly, there was an extraneous
target_include_directories
directive in the CMakeLists.txt for thetests/
subdirectory. The effect of that is already achieved by linking theBlocksRuntime::BlocksRuntime
target and it started tripping up things once switching back tofind_package()
for the runtime lib.Please let me know what you think!
Thanks,
Niels