Problem/Opportunity
There's a certain way software is typically packaged in Linux environments. Especially when talking about development packages that's relevant, as build tools for example have expectations how dependencies can be found. Alas, the current CMake files don't provide a way to produce a package that follows these "guidelines".
Proposed Solution
Expand the CMakeLists.txt in a way that it installs the generated code in standard locations (e.g. /usr/include for headers, /usr/src for source files, and so on). Further, the CMake build system should generate the files that are typically used for dependency resolution in Linux systems (e.g. a pkg-config file, a CMake file for find_module). These should be installed in the correct paths, too.
Iff we want to provide pre-compiled code from the build of this module, both shared objects and static objects shall be created as is usual, so it's up to the implementers which version they want to use based on their use-case. Of course, they have to be installed in their respective directories, too.
Acceptance Criteria (Optional)
Additional Notes (Optional)
This could probably go together with fixes for #635 & #644.
Problem/Opportunity
There's a certain way software is typically packaged in Linux environments. Especially when talking about development packages that's relevant, as build tools for example have expectations how dependencies can be found. Alas, the current CMake files don't provide a way to produce a package that follows these "guidelines".
Proposed Solution
Expand the
CMakeLists.txtin a way that it installs the generated code in standard locations (e.g./usr/includefor headers,/usr/srcfor source files, and so on). Further, the CMake build system should generate the files that are typically used for dependency resolution in Linux systems (e.g. a pkg-config file, a CMake file forfind_module). These should be installed in the correct paths, too.Iff we want to provide pre-compiled code from the build of this module, both shared objects and static objects shall be created as is usual, so it's up to the implementers which version they want to use based on their use-case. Of course, they have to be installed in their respective directories, too.
Acceptance Criteria (Optional)
$PKG_CONFIG_PATH(typically/usr/lib/pkgconfig). It sets at least the following fieldsNameDescriptionRequiresVersionCflagsLibs&Libs.private$CMAKE_MODULE_PATH(typically/usr/share/cmake/). It works analogously to the ones shipped with CMake per default, i.e. can be used withfind_module()without further configuration.find_mdoule().Additional Notes (Optional)
This could probably go together with fixes for #635 & #644.