Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Make library importable by CMake using find_package #708

Closed
wants to merge 10 commits into from

Conversation

ithron
Copy link
Contributor

@ithron ithron commented Jul 17, 2018

Currently no GSLConfig.cmake file was installed so find_package could not be used with GSL.
Fixed CMakeLists.txt to install GSLConfig.cmake so that find_package can be used.
Fixes #715.

@msftclas
Copy link

msftclas commented Jul 17, 2018

CLA assistant check
All CLA requirements met.

Stefan Reinhold added 2 commits July 17, 2018 11:56
CMake war reporting: 'Target "GSL" INTERFACE_SOURCES property contains
path: "..." which is prefixed in the source directory'.
CMake was confused because the $<BUILD_INTERFACE: ...> had linebreaks
in it.
Putting everything in one line fixed the issue.
This fixes an issue where CMake complains about INTERFACE_SOURCES
containing a path which is prefixed in source directory on windows.
@OvermindDL1
Copy link

Doesn't this conflict with GSLConfig.cmake from the GSL scientific library project that this project's name conflicts with? Is there any way to prevent one from overwriting the other on the same system?

This is to avoid conflicts with GNU Scientific Library which also has an
exported target named GSL.
@ithron
Copy link
Contributor Author

ithron commented Jul 17, 2018

Yes, there is a conflict with GNU Scientific Library.
Changed the package name to Microsoft.GSL. The exported target GSL now resides in the namespace Microsoft.GSL::
So:

find_package(Microsoft.GSL)
target_link_libraries(MyTarget PUBLIC Microsoft.GSL::GSL)

I think this might be a good compromise.

@OvermindDL1
Copy link

The namespace is great, but it looks like the filename itself was still GSLConfig.cmake on line 86?

@ithron
Copy link
Contributor Author

ithron commented Jul 17, 2018

Ah, yes, only changed the install line. Fixed that. (Microsoft.GSLConfig.cmake)

@ithron
Copy link
Contributor Author

ithron commented Aug 2, 2018

Should be ready now

@ghost
Copy link

ghost commented Nov 4, 2018

Has this PR gone stale? It is a great initiative to make GSL available as an imported target. This seems to be the standard approach now.

@Warchant
Copy link

Warchant commented Jul 5, 2019

Please land this fix

@pr0g
Copy link

pr0g commented Aug 11, 2019

Hey there,

I wound up implementing this myself recently for a library I wanted to use the GSL with.

I've created a fork here:

https://github.com/pr0g/GSL

and the diff looks like this:

https://github.com/microsoft/GSL/compare/master...pr0g:cmake-find-package.

It's pretty similar to this change - I'm using my fork in my project right now.

I know there's also this PR #784 so I don't want to step on anyone's toes but I would love if support could officially be added. I'd be happy to create a PR with my fork/branch if that would help or try and update this one?

Thanks!

Tom

@JordanMaples
Copy link
Contributor

Maintainer's call: Marking as duplicate of PR #784

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

CMake project not importable using find_package
6 participants