Expose a single canonical flatbuffers::flatbuffers target - #9208
Open
alexreinking wants to merge 1 commit into
Open
Expose a single canonical flatbuffers::flatbuffers target#9208alexreinking wants to merge 1 commit into
alexreinking wants to merge 1 commit into
Conversation
FLATBUFFERS_BUILD_FLATLIB always built flatbuffers::flatbuffers as STATIC, with a separately-typed flatbuffers::flatbuffers_shared only available when FLATBUFFERS_BUILD_SHAREDLIB was explicitly requested. A distro that wants to avoid shipping static libraries (e.g. Fedora's flatbuffers-devel, which builds with -DFLATBUFFERS_BUILD_SHAREDLIB=ON -DFLATBUFFERS_BUILD_FLATLIB=OFF) ends up with a package that never installs FlatBuffersTargets.cmake at all. In this case, find_package(FlatBuffers) reports success, but the canonical flatbuffers::flatbuffers target consumers actually link against silently doesn't exist, so target_link_libraries fails downstream. This applies the design from https://alexreinking.com/blog/building-a-dual-shared-and-static-library-with-cmake.html: flatbuffers never materializes a "_shared"-suffixed physical library. There is exactly one library target (flatbuffers, aliased flatbuffers::flatbuffers), typed by BUILD_SHARED_LIBS/FlatBuffers_SHARED_LIBS like any target without an explicit STATIC/SHARED keyword. Its install(EXPORT) targets file is named for whichever type actually got built (FlatBuffersStaticTargets.cmake or FlatBuffersSharedTargets.cmake), so a packager who wants to offer both flavors runs two separate configure/build/install passes into the same prefix instead of building both from one configure. flatbuffers-config.cmake resolves which one to load with this precedence chain: an explicit `static`/`shared` COMPONENTS request wins, then FlatBuffers_SHARED_LIBS, then BUILD_SHARED_LIBS (falling back to whichever variant is actually installed), then whatever is available, preferring static. flatbuffers::flatbuffers_shared is never a real target -- it's an ALIAS to flatbuffers::flatbuffers, created only when that resolves to a shared library, purely so consumers hardcoded to the legacy name keep working. We also add a deprecation shim for FLATBUFFERS_BUILD_SHAREDLIB to keep downstream build scripts stable, while notifying them of eventual changes to the packaging here. Finally, we add an integration test workflow to GitHub Actions to ensure both single- and multi-configuration install trees resolve as expected, according to the above precedence chain. Fixes google#9206
This file contains hidden or 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
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
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.
FLATBUFFERS_BUILD_FLATLIBalways builtflatbuffers::flatbuffersasSTATIC, with a separately-typedflatbuffers::flatbuffers_sharedonly available whenFLATBUFFERS_BUILD_SHAREDLIBwas explicitly requested. A distro that wants to avoid shipping static libraries (e.g. Fedora'sflatbuffers-devel, which builds with-DFLATBUFFERS_BUILD_SHAREDLIB=ON -DFLATBUFFERS_BUILD_FLATLIB=OFF) ends up with a package that never installsFlatBuffersTargets.cmakeat all. In this case,find_package(FlatBuffers)reports success, but the canonicalflatbuffers::flatbufferstarget consumers actually link against silently doesn't exist, sotarget_link_librariesfails downstream.This applies the design from
https://alexreinking.com/blog/building-a-dual-shared-and-static-library-with-cmake.html: flatbuffers never materializes a
_shared-suffixed physical library. There is exactly one library target (flatbuffers, aliasedflatbuffers::flatbuffers), typed byBUILD_SHARED_LIBS/FlatBuffers_SHARED_LIBSlike any target without an explicitSTATIC/SHAREDkeyword. Itsinstall(EXPORT)targets file is named for whichever type actually got built (FlatBuffersStaticTargets.cmakeorFlatBuffersSharedTargets.cmake), so a packager who wants to offer both flavors runs two separate configure/build/install passes into the same prefix instead of building both from one configure.flatbuffers-config.cmakeresolves which one to load with this precedence chain: an explicitstatic/sharedCOMPONENTSrequest wins, thenFlatBuffers_SHARED_LIBS, thenBUILD_SHARED_LIBS(falling back to whichever variant is actually installed), then whatever is available, preferring static.flatbuffers::flatbuffers_sharedis never a real target -- it's an ALIAS toflatbuffers::flatbuffers, created only when that resolves to a shared library, purely so consumers hardcoded to the legacy name keep working.We also add a deprecation shim for
FLATBUFFERS_BUILD_SHAREDLIBto keep downstream build scripts stable, while notifying them of eventual changes to the packaging here.Finally, we add an integration test workflow to GitHub Actions to ensure both single- and multi-configuration install trees resolve as expected, according to the above precedence chain.
Fixes #9206