Is your feature request related to a problem? Please describe.
Currently the build and install export sets don't understand that static linking means that PRIVATE dependencies are
required to consume an exported library.
This generally means that all projects using rapids-cmake don't properly export dependencies when built statically, since they
only track dependencies that are required to use the library when built 'shared' ( .so )
Describe the solution you'd like
The optimal solution would be to have CMake do the following:
- Associate imported targets with the find_package call that created them
- Allow projects to generate the collection of
find_package calls need by the link rules of the exported targets
If this becomes unreasonable to implement in CMake itself, we can do the following in rapids-cmake:
- Add the
PUBLIC and PRIVATE keywords to rapids_find_package and rapids_cpm_find.
- Extend
rapids_export with a INCLUDE_PRIVATE flag that will be set when building statically.
Is your feature request related to a problem? Please describe.
Currently the build and install export sets don't understand that static linking means that
PRIVATEdependencies arerequired to consume an exported library.
This generally means that all projects using rapids-cmake don't properly export dependencies when built statically, since they
only track dependencies that are required to use the library when built 'shared' ( .so )
Describe the solution you'd like
The optimal solution would be to have CMake do the following:
find_packagecalls need by the link rules of the exported targetsIf this becomes unreasonable to implement in CMake itself, we can do the following in rapids-cmake:
PUBLICandPRIVATEkeywords torapids_find_packageandrapids_cpm_find.rapids_exportwith aINCLUDE_PRIVATEflag that will be set when building statically.