Add CMake package config

[globberwops]

Fixes #35

• Add a project version
• Add package version and config files

[globberwops]

Ping @jpihl @mortenvp @techbech @loglund

[DerThorsten]

Ping @jpihl @mortenvp @techbech @loglund
It would really be nice to have this PR merged as this would simplify the conda-forge build conda-forge/staged-recipes#22527

[jpihl]

Hi @globberwops,

Sorry for the radio silence and thanks for your extensive perseverance 👍

Non of us are very familiar with vcpkg not do we understand the need for your changes in the cmake file. Would you care to elaborate on the motivation for the changes?

All the best

Jeppe

[globberwops]

Hi @jpihl, no worries! Thanks for your reply.

These changes are only loosely related to vcpkg.
The primary purpose of a CMake package config is for CMake to be able to find the lib with a call to find_package in a downstream project, see cmake-packages(7).

Once installed, CMake will be able to find the file recycle-config.cmake, which in turn includes recycle-targets.cmake.
The latter defines imported targets that can be linked in the downstream project to provide the location of the lib and the corresponding include path.

vcpkg is just one of the package managers that rely on CMake to provide package config files.
However, vcpkg is by no means needed to consume the package configs.

I hope that helps.

Cheers,
Martin

[jpihl]

Thanks, that cleared up a few things.
I still need to understand all the changes before I feel comfortable merging this one. I will add a few comments inline, and I hope you'll be able to help me understand everything. As I mentioned, I only have a little experience with CMake Packages.

[jpihl]

What is the difference between this and the original?

[globberwops]

The include path in the BUILD_INTERFACE is used during the build of this project, and the include path in the INSTALL_INTERFACE will be used by downstream projects that use an installed version of this project.

During the build of this project, the headers are located in src, but they will be installed in <INSTALL_PREFIX>/include (according to GNU convention).
This is why we have to differentiate and tell CMake, where to find the headers in both cases.

[jpihl]

I see, so if the library is being used as a CMake Package, INSTALL_INTERFACE will be used, but if it's being used with, e.g.,
add_subdirectory or FetchContent_Declare, BUILD_INTERFACE will be used?
Is this correctly understood?

[globberwops]

Exactly 👍🏻

[jpihl]

In our internal projects, we use add_subdirectory for dependencies. I just tried using these changes, and I got this error:

[cmake] CMake Error in resolve_symlinks/slide/CMakeLists.txt:
[cmake]   Target "recycle" contains relative path in its
[cmake]   INTERFACE_INCLUDE_DIRECTORIES:
[cmake] 
[cmake]     "src"
[cmake] 
[cmake] 
[cmake] -- Generating done
[cmake] CMake Generate step failed.  Build files cannot be regenerated correctly.

I search a little and found this, so it seems the BUILD_INTERFACE needs to have ${CMAKE_CURRENT_SOURCE_DIR} prepended. At least that fixed the error.

[jpihl]

Hi, @globberwops; if you make this change, we should be able to merge this one finally ;-)

Cheers!

[globberwops]

@jpihl Done! Thanks for the reminder :)

[jpihl]

I need help understanding the purpose of lines 24-29.

[globberwops]

This call will create the file recycle-targets.cmake in the dir ${RECYCLE_CONFIG_DIR}.
The targets defined in this file will be prefixed with steinwurf::.

Downstream projects can then link these targets e.g.

find_package(recycle)
target_link_libraries(<TARGET> PUBLIC steinwurf::recycle)

[jpihl]

Why is the NO_CHECK_REQUIRED_COMPONENTS_MACRO option set?

[globberwops]

By default, configure_package_config_file will put a macro into the package config file that can be used to check, if all components of the package can be found, e.g.

find_package(Boost COMPONENTS regex log)

Since this project does not have any components, we disable the macro.