# The FindGLEW.cmake module does not set GLEW\_LIBRARIES in some cases

**URL:** <https://discourse.cmake.org/t/the-findglew-cmake-module-does-not-set-glew-libraries-in-some-cases/989>\
**Category:** Code\
**Tags:** os:windows\
**Created:** [April 11, 2020, 6:19pm UTC](https://discourse.cmake.org/t/the-findglew-cmake-module-does-not-set-glew-libraries-in-some-cases/989 "2020-04-11T18:19:41Z")\
**Posts on this page:** 14\
**Page:** 1

<div class="post-metadata">

**Author:** ![geoffmcl](https://discourse.cmake.org/user_avatar/discourse.cmake.org/geoffmcl/32/509_2.png) [@geoffmcl](https://discourse.cmake.org/u/geoffmcl)\
**Post date:** [April 11, 2020, 6:19pm UTC](https://discourse.cmake.org/t/the-findglew-cmake-module-does-not-set-glew-libraries-in-some-cases/989/1 "2020-04-11T18:19:41Z")

</div>

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.

---

<div class="post-metadata">

**Author:** ![ben.boeckel](https://discourse.cmake.org/letter_avatar_proxy/v4/letter/b/ea5d25/32.png) [@ben.boeckel](https://discourse.cmake.org/u/ben.boeckel)\
**Post date:** [April 11, 2020, 11:17pm UTC](https://discourse.cmake.org/t/the-findglew-cmake-module-does-not-set-glew-libraries-in-some-cases/989/2 "2020-04-11T23:17:47Z")

</div>

It looks like [`glew-config.cmake`](https://github.com/nigels-com/glew/blob/e544f8c12d209618fd69bccd3c4414893c142ba7/build/cmake/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.

---

<div class="post-metadata">

**Author:** ![geoffmcl](https://discourse.cmake.org/user_avatar/discourse.cmake.org/geoffmcl/32/509_2.png) [@geoffmcl](https://discourse.cmake.org/u/geoffmcl)\
**Post date:** [April 12, 2020, 2:10pm UTC](https://discourse.cmake.org/t/the-findglew-cmake-module-does-not-set-glew-libraries-in-some-cases/989/3 "2020-04-12T14:10:20Z")

</div>

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 -

```cmake
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…

---

<div class="post-metadata">

**Author:** ![ben.boeckel](https://discourse.cmake.org/letter_avatar_proxy/v4/letter/b/ea5d25/32.png) [@ben.boeckel](https://discourse.cmake.org/u/ben.boeckel)\
**Post date:** [April 12, 2020, 3:40pm UTC](https://discourse.cmake.org/t/the-findglew-cmake-module-does-not-set-glew-libraries-in-some-cases/989/4 "2020-04-12T15:40:42Z")

</div>

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.

---

<div class="post-metadata">

**Author:** ![ben.boeckel](https://discourse.cmake.org/letter_avatar_proxy/v4/letter/b/ea5d25/32.png) [@ben.boeckel](https://discourse.cmake.org/u/ben.boeckel)\
**Post date:** [April 12, 2020, 3:41pm UTC](https://discourse.cmake.org/t/the-findglew-cmake-module-does-not-set-glew-libraries-in-some-cases/989/5 "2020-04-12T15:41:45Z")

</div>

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.

---

<div class="post-metadata">

**Author:** ![geoffmcl](https://discourse.cmake.org/user_avatar/discourse.cmake.org/geoffmcl/32/509_2.png) [@geoffmcl](https://discourse.cmake.org/u/geoffmcl)\
**Post date:** [April 13, 2020, 4:41pm UTC](https://discourse.cmake.org/t/the-findglew-cmake-module-does-not-set-glew-libraries-in-some-cases/989/6 "2020-04-13T16:41:43Z")

</div>

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 -

```auto
-- === 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 -

```auto
-- === 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…

---

<div class="post-metadata">

**Author:** ![ben.boeckel](https://discourse.cmake.org/letter_avatar_proxy/v4/letter/b/ea5d25/32.png) [@ben.boeckel](https://discourse.cmake.org/u/ben.boeckel)\
**Post date:** [April 13, 2020, 5:28pm UTC](https://discourse.cmake.org/t/the-findglew-cmake-module-does-not-set-glew-libraries-in-some-cases/989/7 "2020-04-13T17:28:43Z")

</div>

> [@geoffmcl](#):
>
> In a quick check, it seems `if (GLEW::GLEW)` or `if (GLEW::glew)` both FAIL!

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

> [@geoffmcl](#):
>
> shows some, like RTI, OpenAL, … maybe more, that do not seem to yet set `imported target` … so it is certainly not 100%, yet…

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

> [@geoffmcl](#):
>
> And now note GLEW\_INCLUDE\_DIRS is also **not** defined!

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).

---

<div class="post-metadata">

**Author:** ![geoffmcl](https://discourse.cmake.org/user_avatar/discourse.cmake.org/geoffmcl/32/509_2.png) [@geoffmcl](https://discourse.cmake.org/u/geoffmcl)\
**Post date:** [April 19, 2020, 7:35pm UTC](https://discourse.cmake.org/t/the-findglew-cmake-module-does-not-set-glew-libraries-in-some-cases/989/8 "2020-04-19T19:35:55Z")

</div>

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 -

```auto
   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…

---

<div class="post-metadata">

**Author:** ![ben.boeckel](https://discourse.cmake.org/letter_avatar_proxy/v4/letter/b/ea5d25/32.png) [@ben.boeckel](https://discourse.cmake.org/u/ben.boeckel)\
**Post date:** [April 20, 2020, 12:38pm UTC](https://discourse.cmake.org/t/the-findglew-cmake-module-does-not-set-glew-libraries-in-some-cases/989/9 "2020-04-20T12:38:09Z")

</div>

> [@geoffmcl](#):
>
> But, unfortunatley, the **missing** variables of GLEW\_LIBRARIES **and** GLEW\_INCLUDE\_DIRS persists…

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

> [@geoffmcl](#):
>
> `message(STATUS "*** GLEW libs GLEW::GLEW=${GLEW::GLEW}")` I get a stange error message of -

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.

> [@geoffmcl](#):
>
> 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… ;=))

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`.

> [@geoffmcl](#):
>
> 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…

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?

---

<div class="post-metadata">

**Author:** ![hsattler](https://discourse.cmake.org/letter_avatar_proxy/v4/letter/h/59ef9b/32.png) [@hsattler](https://discourse.cmake.org/u/hsattler)\
**Post date:** [April 21, 2020, 3:01pm UTC](https://discourse.cmake.org/t/the-findglew-cmake-module-does-not-set-glew-libraries-in-some-cases/989/10 "2020-04-21T15:01:44Z")

</div>

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

> include(FindPackageHandleStandardArgs)  
> find\_package\_handle\_standard\_args(Qt5 CONFIG\_MODE)

---

<div class="post-metadata">

**Author:** ![geoffmcl](https://discourse.cmake.org/user_avatar/discourse.cmake.org/geoffmcl/32/509_2.png) [@geoffmcl](https://discourse.cmake.org/u/geoffmcl)\
**Post date:** [April 21, 2020, 6:32pm UTC](https://discourse.cmake.org/t/the-findglew-cmake-module-does-not-set-glew-libraries-in-some-cases/989/11 "2020-04-21T18:32:45Z")

</div>

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 -

```auto
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…

---

<div class="post-metadata">

**Author:** ![ben.boeckel](https://discourse.cmake.org/letter_avatar_proxy/v4/letter/b/ea5d25/32.png) [@ben.boeckel](https://discourse.cmake.org/u/ben.boeckel)\
**Post date:** [April 27, 2020, 1:33pm UTC](https://discourse.cmake.org/t/the-findglew-cmake-module-does-not-set-glew-libraries-in-some-cases/989/12 "2020-04-27T13:33:20Z")

</div>

> [@geoffmcl](#):
>
> but the 6 lines below introduce the problem

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.

---

<div class="post-metadata">

**Author:** ![geoffmcl](https://discourse.cmake.org/user_avatar/discourse.cmake.org/geoffmcl/32/509_2.png) [@geoffmcl](https://discourse.cmake.org/u/geoffmcl)\
**Post date:** [April 27, 2020, 3:21pm UTC](https://discourse.cmake.org/t/the-findglew-cmake-module-does-not-set-glew-libraries-in-some-cases/989/13 "2020-04-27T15:21:59Z")

</div>

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
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…

---

<div class="post-metadata">

**Author:** ![geoffmcl](https://discourse.cmake.org/user_avatar/discourse.cmake.org/geoffmcl/32/509_2.png) [@geoffmcl](https://discourse.cmake.org/u/geoffmcl)\
**Post date:** [May 12, 2020, 3:42pm UTC](https://discourse.cmake.org/t/the-findglew-cmake-module-does-not-set-glew-libraries-in-some-cases/989/14 "2020-05-12T15:42:04Z")

</div>

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