CMake project not importable using find_package

[ithron]

Currently no GSLConfig.cmake file is installed so find_package can not be used with GSL.

Exporting the targets and having an install script is a crucial requirement for GSL to be used with CMake based package manager like hunter. Even without any package manager find_package is the most clean way to import dependencies in CMake.

The CMakeLists.txt should be changed to include an export and install rule.

[FlorianWolters]

Is anyone working on this currently? I've seen that multiple (faulty) pull requests have been denied for the Microsoft GSL. I suggest using a different name though, since CMake ships with a FindGSL module for the GNU Scientific Library. Instead MicrosoftGSL should be used as the package name, i.e. the upstream should install a MicrosoftGSLConfig.cmake file that provides a MicrosoftGSL::GSL target for its INTERFACE library.

What's the state with the PR #708, it is still open and the CI build fails (but it seems not due to the CMakeLists.txt changes)?

[ithron]

Good point, GSLConfig.cmake should be installed as Microsoft.GSLConfig.cmake.
Currently the namespace is named Microsoft.GSL so the target is Microsoft.GSL::GSL.
Could also be renamed to MicrosoftGSL.

I've no clue why the CI builds fail. Yes, probably not caused by the CMakeLists.txt. Somehow no test executables are created, so no tests are run.

I'm currently quite busy. Probably won't have time to look into it until end of October.

Btw. I also created a hunter package for MicrosoftGSL tags 1.0.0 and 2.0.0.

[FlorianWolters]

I've never seen CMake namespaces with dots included, so instead of Microsoft.GSL I suggest using MicrosoftGSL.

I do think things should be seperated (via multiple PRs):

1. Add CMake config-file package support.
2. Add Conan support.
3. Add Hunter support.

Maybe I find some time implementing a working CMake config-file package build, but I can't promise.

Points 2 and 3 are discussable. I suggest adding the support to upstream if possible. The alternative is using forks adding the package management support, which is bad imo. Point 1 is absolutely mandatory, though.

[Jerry-Ma]

Also, the config file should support usage from both installed tree (project installed externally or via ExternalProject_Add) and build tree (project included via FetchContent and add_subdirectory).

[Adnn]

We would also require this to produce a CMake package to be usable in our projects.

I have been trying to dig around a bit, and it see the current linked #708 has been closed as a duplicate of still open #784. This last PR is all green, are there any specific problems to be addressed before merging it in? (asking because this issue has been tagged with help wanted)

[gocarlos]

should be fixed since 3.0.0

[leha-bot]

I also implement find_package version support in #879

[JordanMaples]

As far as I know this issue has been addressed by a few different PRs. Please reactivate this or file a new issue if there is still a problem with the current find_package logic. Thanks.