Closed Rodousse closed 3 years ago
I’m happy to see using glew-cmake.
I made glew-cmake when there was no cmake support for glew. At now, official glew has its CmakeLists. So, I decided to maintain glew-cmake not to break some projects depends on this. It is the only reason why I keep weird points in cmake.
Got it, I did not realize this was maintain for old project support. Thanks for the info and taking the time to reply !
Hello,
Thank you so much for this adaptation of glew with cmake, this is wonderful !
I have a small question concerning the coherency between the target specified in the
FindGlew.cmake
and the exported one we find in theglewConfig.cmake
files.Is there any reasons why you did not name the exported target the same way as in the
FindGlew.cmake
?They already have a convention for the naming and the alias
GLEW::GLEW
to select the right target between the static and the shared one depending on the value ofGLEW_USE_STATIC_LIBS
which is quiet convenient.For instance when you specify the value of
BUILD_SHARED_LIBS
and you want to link with third party libraries of the same type I like to use this alias target and just set the value ofGLEW_USE_STATIC_LIBS
instead of storing the right target in a cmake variable. (I'm nitpicking here)The thing is that you can easily have two kind of users, the ones who have the library installed with the original repository and the ones that will use your project. If there are the same targets in both repo, and one wants to switch from one project to another, he/she just has to set the
find_package(glew MODULE)
tofind_package(glew CONFIG)
and the targets used in the project will remain the same.I'm sure there is a perfectly valid answer to this, and if you could clarify this to me @Perlmint I would much appreciate it, thank you very much !