The FindGLEW.cmake module does not set GLEW_LIBRARIES in some cases

Code
1

This is my first post here, and maybe this problem should be posted elsewhere…

If the cmake find_package(GLEW) finds lib/cmake/glew/glew-config.cmake, etc, it FAILS to set GLEW_LIBRARIES…

It does however set GLEW_LIBRARY_DEBUG AND GLEW_LIBRARY_RELEASE.

Is this a bug, or am I doing something wrong?

Thanks… Geoff.

2

It looks like glew-config.cmake makes a GLEW::glew target. CMake’s FindGLEW also seems to make the same target, so I recommend using it rather than GLEW_LIBRARIES at all. You’ll also be able to drop GLEW_INCLUDE_DIRS as well.

3

Hi Ben, thank you for your reply…

I had already noted that I could use the alias GLEW::GLEW…

Here are snippets of the defensive code, added -

find_package(GLEW QUIET)
if(NOT GLEW_FOUND)
  message(WARNING "GLEW NOT found, can't build FGPanel")
  set(WITH_FGPANEL 0)
  return()
endif()
if(NOT GLEW_LIBRARIES)
  if(GLEW_LIBRARY_DEBUG AND GLEW_LIBRARY_RELEASE)
    set(GLEW_LIBRARIES "optimized;${GLEW_LIBRARY_RELEASE};debug;${GLEW_LIBRARY_DEBUG}")
  else()
    set(GLEW_LIBRARIES GLEW::GLEW)
  endif()
endif()
add_executable(fgpanel ${TARGET_SOURCES})
target_link_libraries(fgpanel ... ${GLEW_LIBRARIES})
target_include_directories(fgpanel PUBLIC ... ${GLEW_INCLUDE_DIRS})

The point is, the code needs to work whether the GLEW install process adds a glew-config.cmake, … I have cases where that is /NOT/ true… like when you download the offered binaries GLEW windows ZIP… headers, libraries - but no cmake CONFIG…

And the cmake FindGLEW.cmake ‘promises’ Result Variables that includes GLEW_LIBRARIES and GLEW_INCLUDE_DIRS…

So, as stated, this seems a cmake BUG! Or at least a broken promise ;=))

Also curious why you think GLEW_INCLUDE_DIRS can be dropped, but that is a little off topic…

Look forward to further feedback, to try to understand… thanks…

4

If your Windows package is missing glew-config.cmake, what is find_package calling? CMake’s FindGLEW? It also makes the imported target. Just use that instead of the variables.

5

Oh! I see. Sorry, I think I misread the first time. Please file an issue. However, in the meantime, I suggest just using the imported target anyways.

6

Hi Ben, again thank you for your replies…

Yes, I am using the cmake’s FindGLEW.cmake… And the setting GLEW_LIBRARIES absolutely depends on whether a glew-config.cmake, etc, is found, or not… if I move these files away, or point to a GLEW installation with no such cmake CONFIG files, then GLEW_LIBRARIES is correctly defined…

Now this project, fgpanel is part of a much larger project, flightgear, and actually has a considerable number of 3rdParty dependencies, like PNG, ZLIB, OpenGL, Freetype, GLUT, … and this missing GLEW_LIBRARIES is the only one causing a LINK problem. But experimenting, making trial changes, in such a big project is very slow and time consuming…

But I have now been able to separate this source, into a single project… where testing, trials, changes, … is much easier, and faster…

And now note GLEW_INCLUDE_DIRS is also not defined! This was being masked by other dependencies already defining the required target_include_directories(…), of X:\3rdParty.x64\include, so did not note it being blank…

And now I see I last built, and installed, this GLEW was back in Feb 2018, so this would have been with a much older cmake version, than my current 3.16.4.

Could it be that maybe these GLEW cmake CONFIG files were mal-formed, or incomplete? I will try to recompile GLEW, probably a later version, and do a new install… to see if that does anything… but this will take a few days, maybe a week, or so… unfortunately…

Now, each time you have mentioned using the imported target, and we could adjust to that, but how do you detect that such aliases, if that is what they are called, do exist? Are available?

In a quick check, it seems if (GLEW::GLEW) or if (GLEW::glew) both FAIL! It seems if (GLEW_DIR) does work, but seems odd, strange…

Simply, what is the approved method to signal the use of imported target?

A brief review of the some 160 FindXXXX.cmake in the gitlab.kitware repo, as of Apr 10, 2020, shows some, like RTI, OpenAL, … maybe more, that do not seem to yet set imported target… so it is certainly not 100%, yet…

And to again stress the point, here is what is defined by FindGLEW.cmake, if the glew-config.cmake files are NOT present -

-- === GLEW_CONSIDERED_CONFIGS=
-- === GLEW_CONSIDERED_VERSIONS=
-- === GLEW_DIR=GLEW_DIR-NOTFOUND
-- === GLEW_FOUND=TRUE
-- === GLEW_INCLUDE_DIR=X:/3rdParty.x64/include
-- === GLEW_INCLUDE_DIRS=X:/3rdParty.x64/include
-- === GLEW_LIBRARIES=optimized;X:/3rdParty.x64/lib/glew32.lib;debug;X:/3rdParty.x64/lib/glew32d.lib
-- === GLEW_SHARED_FOUND=TRUE
-- === GLEW_SHARED_LIBRARIES=optimized;X:/3rdParty.x64/lib/glew32.lib;debug;X:/3rdParty.x64/lib/glew32d.lib
-- === GLEW_SHARED_LIBRARY=optimized;X:/3rdParty.x64/lib/glew32.lib;debug;X:/3rdParty.x64/lib/glew32d.lib
-- === GLEW_SHARED_LIBRARY_DEBUG=X:/3rdParty.x64/lib/glew32d.lib
-- === GLEW_SHARED_LIBRARY_RELEASE=X:/3rdParty.x64/lib/glew32.lib
-- === GLEW_STATIC_FOUND=TRUE
-- === GLEW_STATIC_LIBRARIES=X:/3rdParty.x64/lib/glew32s.lib
-- === GLEW_STATIC_LIBRARY=X:/3rdParty.x64/lib/glew32s.lib
-- === GLEW_STATIC_LIBRARY_DEBUG=GLEW_STATIC_LIBRARY_DEBUG-NOTFOUND
-- === GLEW_STATIC_LIBRARY_RELEASE=X:/3rdParty.x64/lib/glew32s.lib
-- === GLEW_VERSION=2.1.0
-- === GLEW_VERSION_MAJOR=2
-- === GLEW_VERSION_MICRO=0
-- === GLEW_VERSION_MINOR=1

And when glew-config.cmake, et al is present -

-- === GLEW_CONFIG=X:/3rdParty.x64/lib/cmake/glew/glew-config.cmake
-- === GLEW_CONSIDERED_CONFIGS=X:/3rdParty.x64/lib/cmake/glew/glew-config.cmake
-- === GLEW_CONSIDERED_VERSIONS=unknown
-- === GLEW_DIR=X:/3rdParty.x64/lib/cmake/glew
-- === GLEW_FOUND=TRUE
-- === GLEW_VERSION_COUNT=0
-- === GLEW_VERSION_MAJOR=0
-- === GLEW_VERSION_MINOR=0
-- === GLEW_VERSION_PATCH=0
-- === GLEW_VERSION_TWEAK=0

Chaulk and cheese ;=))

This is done through get_cmake_property(_variableNames VARIABLES), then outputing in a foreach… Maybe there is a better way, to get a more complete list… appreciate any help on that…

As stated, will get around to re-building and installing GLEW, to see if that changes anything…

And if not will try to get around to filing an issue…

But meantime, hope someone can help with detecting imported target … thanks…

7

You want if (TARGET GLEW::glew). As for use, just do target_link_libraries(glew-user ${visibility} GLEW::glew).

Imported targets are added as modules get updated for other reasons. I guess those haven’t been updated since we started doing that.

Yes, this should be part of the issue to make the API surface look the same from FindGLEW.cmake whether or not the glew-config.cmake ends up being used (find_package(GLEW CONFIG) still won’t have these variables since CMake doesn’t control that).

8

Hi Ben, again thank you for your reply…

Took me some time, as expected, to get, build and install a later version of GLEW… many false steps along the way… but now DONE… installed in D:\Projects\3rdPary.x64, in /bin, /include, /lib, especially /lib/cmake/glew/glew_config.cmake… etc…

But, unfortunatley, the missing variables of GLEW_LIBRARIES and GLEW_INCLUDE_DIRS persists…

Yes, it seems if (TARGET GLEW::GLEW) does work… thanks…

But how to view the content of GLEW::GLEW? If I try message(STATUS "*** GLEW libs GLEW::GLEW=${GLEW::GLEW}") I get a stange error message of -

   syntax error, unexpected cal_SYMBOL, expecting } (38)

Of course this content message is only for diagnostic review of exactly what library, or libraries, are being used. And is nothing to do with its use, which, as you wrote, remains target_link_libraries(glew-user ${visibility} GLEW::glew)…

But it is sometimes an important aid… a clue to certain link errors…

And I am studying other packages, that create/install an IMPORT Target CONFIG, to see how this problem is addressed in other projects. But this is slow going… Any pointers to good docs would be appreciated… or some good examples to follow… thanks…

The problem is, so far, I can not find any of these CONFIG files that explicitly set, say <PROJ>_LIBRARIES or <proj>_INCLUDE_DIRS, yet, in the few I have tested further with, somehow these variables do seem to get SET… then you say CMake doesn’t control that? … still a big mystery… ;=))

Any help appreciated… thanks…

9

This needs a CMake change to address. Please file an issue.

Imported targets are not variables and : is an invalid (literal) variable name, hence the error message. Though I suspect you’re not using CMP0053 set to NEW which has a better error message for that I think.

If you want to see what that target is, you’ll have to ask it about its properties. IMPORTED_LOCATION is probably the best one to start with. INTERFACE_INCLUDE_DIRECTORIES is likely the other one in this case.

This is probably happening when find_package is trampolined through a FindFoo.cmake module which then chains off to the foo-config.cmake module. The Find variant is likely backfilling variables from its original set from the config module. That step is what is incomplete in FindGLEW.

It’s a bit convoluted, but VTK does this. Basically, when using imported targets, you should find_package in your config.cmake module again. The find_dependency macro (from the FindDependency module) is likely useful for simpler projects that don’t have component searching support.

@craig.scott Do you know of good resources for this case?

10

To print a message during configure for config modules, I use for Qt5:

include(FindPackageHandleStandardArgs)
find_package_handle_standard_args(Qt5 CONFIG_MODE)

11

Thanks for the further feedback…

Yes, I will get to filing an issue, but I was hoping I could include a tested patch, or even a Merge Request ;=)) At least if the fault is only in FindGLEW.cmake module…

So, as previously indicated, if I move away/delete the .../lib/cmake/glew/glew_config.cmake files, all works well, but the 6 lines below introduce the problem -

find_package(GLEW CONFIG QUIET)

if(GLEW_FOUND)
  find_package_handle_standard_args(GLEW DEFAULT_MSG GLEW_CONFIG)
  return()
endif()

That was other reason I asked how can I view/print/output the contents of TARGET GLEW::GLEW… to maybe add a few more lines, before the above return(), to be able to explicitly SET the missing GLEW_LIBRARIES, GLEW_INCLUDE_DIRS and now add the GLEW_VERSION_XXXX variables…

I have still to explore say get_target_property(VAR target property) to see what this gives me… this is all quite new to me… so will take some time…

I have already done a VTK-8.2.0 build… and produced over 120 DLL’s, but not sure what this gained me?

And Hendrik, doesn’t the above code already do, more or less, what you suggest? Maybe the GLEW_CONFIG could be changed to CONFIG_MODE??

I have also done an extensive cmake src git log search, and see this CONFIG stuff was introduced about a year, or so, ago, through quite a number of commits… some fixing issue introduced…

And found this CONFIG TARGET stuff was not present in my FindGLEW.cmake for cmake 3.5, my previous version, since circa 2016, which is why I had not run across it earlier… only after a cmake update…

Anyway, maybe I will fail, or just give up, and file an issue ;=))

Any further feedback here would be appreciated… thanks…

12

The return() is the actual problem here. Logic needs to go before it to add the variables the other codepath ends up using with the information from the config module.

13

Again, thanks for the further feedback…

That is exactly what I tried to do - that is add code before the return(), to add the missing variable, but the question was how to use just the information from the config modules…

One is maybe ok, like GLEW_LIBRARIES, which you could set to GLEW::GLEW, or GLEW::glew, and cmake would later expand that to a <path>/library… but as previously requested, still seek a way to output the full path, for diagnostic purposes…

And can NOT find any way to set GLEW_INCLUDE_DIRS, or the GLEW_VERSION_XXXX variables… without doing what is done later, if the CONFIG is not found…

Namely find_path(GLEW_INCLUDE_DIR GL/glew.h), then file(STRINGS "${GLEW_INCLUDE_DIR}/GL/glew.h" _contents REGEX "^VERSION_.+ [0-9]+"), etc, etc…that path and version information just does NOT exist in the CONFIG files…

I went back and re-read the tutorial… wow, it has certainly expanded in the intervening years… copied and built the complete tutorial… even found what I think is a small BUG in the MathFunctions/CMakeLists.txt… my small diff -

diff --git a/Help/guide/tutorial/Complete/MathFunctions/CMakeLists.txt b/Help/guide/tutorial/Complete/MathFunctions/CMakeLists.txt
index c911625b80..e7751d40fd 100644
--- a/Help/guide/tutorial/Complete/MathFunctions/CMakeLists.txt
+++ b/Help/guide/tutorial/Complete/MathFunctions/CMakeLists.txt
@@ -58,6 +58,8 @@ set_property(TARGET MathFunctions PROPERTY SOVERSION "1")
 
 # install rules
 install(TARGETS MathFunctions tutorial_compiler_flags
-        DESTINATION lib
-        EXPORT MathFunctionsTargets)
+        EXPORT MathFunctionsTargets
+        RUNTIME DESTINATION bin
+        LIBRARY DESTINATION lib
+        ARCHIVE DESTINATION lib)
 install(FILES MathFunctions.h DESTINATION include)

In windows at least, a DLL should be installed to the bin directory, not ALL to the lib folder… but that is off topic…

And then I built a small test-tut app, to use the MathFunctions.dll, and a FindMathFunctions.cmake, based on FindGLEW.cmake, and it too FAILED… so did a lot of experimenting with it… lots of insertions before the return() ;=)) did achieve some very kludgy successes…

Anyway, I am running out of ideas, and steam, without further information, so will try to get around to filing an issue… if someone does not beat me to it…

Thanks for all your help… I have learned a lot along the way… but seemingly still not enought about TARGETs… especially about why it seems this in the new, preferred? way forward…

And have now come across some other projects that are having problems with TARGET vs variables, usually after a cmake version upgrade… but they are trying to adjust…

I know, it takes time to get all the documentation, information, examples, etc, in place… in the open s/w voluntary world… so will be patient…

14

Have now submitted an issue - https://gitlab.kitware.com/cmake/cmake/-/issues/20699

1 Like