cmake: link static target to static dependencies #536
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
adammoody
force-pushed
the
statictarget
branch
3 times, most recently
from
ca7a8bf
to
8695be1
Compare
This was referenced May 10, 2023
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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.
This PR makes the following changes:
scr::scrlinks to the shared objects for SCR and its dependent libraries whilescr::scr-staticlinks to the static libraries of SCR and its dependencies (where available).scrConfig.cmakein the application integration section of the SCR docs.The current PR implements the second option listed below, which was copied from a related PR #529.
When trying a full static build and using the new cmake package config files to specify dependencies, we hit problems where some targets are looking for non-static targets of dependencies (which are not installed when the components are build static-only). This is closely related to the problem reported in: #513
One option is to support two link options, where we have the static-only link specify the static targets of all dependencies. So if we only build libscr.a (not libscr.so) we link libscr.a to the .a builds of all components. If we build libscr.so, then we link everything to .so, including linking libscr.a to the .so versions of all components. That is the approach this PR takes. Similar changes need to be done for all components if we opt for this route. I have those ready.
As a second option, we could change this so that scr::scr points at the shared objects for all dependencies and have scr::scr-static point to the -static versions of all dependencies.
As yet a third option, the article linked below suggests a way in which we'd only provide a single scr::scr target and then to make our scrConfig.cmake script smart enough to have that target point at either libscr.so or libscr.a depending on how the user has set BUILD_SHARED_LIBS:
https://alexreinking.com/blog/building-a-dual-shared-and-static-library-with-cmake.html
That's nice since the end user only needs to link to scr::scr but they can flip between shared and static versions of libscr by setting BUILD_SHARED_LIBS during their application build.