-
Notifications
You must be signed in to change notification settings - Fork 160
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
CMake < 18 support is broken since 0.13 #209
Comments
I can't judge if the latter is equivalent. I'd be fine with the version guard, as it should be the safe option. Unless someone can confirm that the latter is safe, too... |
daschuer
referenced
this issue
Jan 13, 2022
QtKeychain defines an exported CMake target (qt5keychain), but the name does not follow the CMake convention (Foo::Bar). This is confusing at best, especially given the name is the same as the plain library. It is not clear to the reader whether `target_link_libraries(foo PRIVATE qt5keychain)` links to an imported target or a plain library. Add an alias Qt5KeyChain::Qt5KeyChain with a more conventional name. This preserves compatibility for users that rely on the qt5keychain target.
daschuer
added a commit
to daschuer/qtkeychain
that referenced
this issue
Jan 25, 2022
This fixes building with cmake < version 18 a regression form 70a567a issue frankosterfeld#209
Merged
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
This has happened due to 70a567a
which requires CMake >= 18.0
An easy fix would be to add a version guard around the ALIAS creation.
An alternative is proposed in the related CMake issue https://gitlab.kitware.com/cmake/cmake/-/issues/20641
Is this equivalent?
The text was updated successfully, but these errors were encountered: