Hello,

On the main page it says that the version of the project is up to release 2.1.0
But there is no tag that corresponds to it.
Could one be made please?

V/R,
--Maxim

When cloning the branch glew-cmake-release the CMakeFiles.txt script will crash at line 12 trying to execute include("GeneratePkgConfig.cmake") since the file is missing.

Hey,

just had loads of build errors pop up, seems like sth went rather wrong, e.g. glew.c now features garbage like this:
static GLboolean _glewInit_GL_ARB_ES3_1_compatibility ()
{
GLboolean r = GL_FALSE;

r = glewInit(GLbitfield() || r;
r = _glewInit_barriers)() || r;
r = _glewInit_glMemoryBarrierByRegion() || r;
r = _glewInit_void() || r;

return r;
}
Any ideas?

Thx!

When doing

cmake ..

I get:

CMake Error at CMakeLists.txt:79 (INSTALL):
  INSTALL TARGETS given no LIBRARY DESTINATION for shared library target
  "libglew_shared".


CMake Error at CMakeLists.txt:94 (INSTALL):
  INSTALL TARGETS given no LIBRARY DESTINATION for shared library target
  "libglewmx_shared".


-- Configuring incomplete, errors occurred!

I bisected. This is caused by the merge:

commit e4de8a7
Merge: f92c14b 5a7232f
Author: Gyusun Yeom [email protected]
Date: Sat Apr 20 15:45:09 2019 +0900

Merge pull request #16 from GekkieHenkie/patch-1

Update library install directories in Cmake

commit 5a7232f
Author: GekkieHenkie [email protected]
Date: Tue Apr 9 23:59:48 2019 +0200

Install directories set in single statement

commit def19e7
Author: GekkieHenkie [email protected]
Date: Tue Apr 9 23:22:16 2019 +0200

Update library install directories in Cmake

Currently (well, at least on Windows), the created DLL files aren't installed to the correct directory after a build. The DLL files are installed to the 'lib' directory. Which actually is the place for the static library or the shared library's symbols file (.lib).
The shared library runtimes should be installed to the 'bin' output directory, as proposed in this PR.

See the ```CONFIGURATIONS``` option in [Install command introduction in the CMake manual](https://cmake.org/cmake/help/v3.14/command/install.html#introduction) for an example.

It's considered best practice and follows convention as used in other notable libraries as libpng, libogg/vorbis, freetype, zlib, tinyxml, etc, to install the runtime output in the 'bin' directory.

Using CMAKE_SOURCE_DIR makes it so the library is built in the wrong directory when added to the project via FetchContent and then adding it using something like add_subdirectory(${glew_SOURCE_DIR} ${glew_BINARY_DIR})

Hi !
This is more of a question than a real issue, but I don't really know where to ask this appart from here.
I am trying to use EGL on Windows, and when I include eglew.h, the compiler complains about missing EGL/eglplatform.h and KHR/khrplatform.h
Am I missing something there ?
Is there a specific way of using EGL on Windows ?

It looks like the usual distributions ship glew as libGLEW.so instead of libglew.so which should be no problem as long as the pkg-config files is used to determine linker flags.

https://github.com/archlinux/svntogit-packages/blob/packages/glew/trunk/PKGBUILD#L13

But some programs have a hardcoded lib detection like this:

https://github.com/duganchen/dosbox/blob/master/configure.ac#L469-L471

Could you add a symlink libGLEW.so to libglew.so for compatibility purposed? I guess this will be just a single line of code.

we have added glew as a submodule in our project and after generating with cmake using ninja when i try to build it in vs code i get an error
[build] lib/glew-cmake/CMakeFiles/libglew_shared.dir/src/glew.c.obj:glew.c:(.text+0x2f0d1): multiple definition of 'DllMainCRTStartup' [build] D:/MinGW/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/8.1.0/../../../../x86_64-w64-mingw32/lib/../lib/dllcrt2.o:crtdll.c:(.text+0x330): first defined here i know that this is specific to windows users after looking at glew.c but i have not been able to solve it, any help would be appreciated

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 the glewConfig.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 of GLEW_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 of GLEW_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) to find_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 !

You have neither up-to-date / reliable tags or commit IDs that don't change, every single time you pull/update from whatever cmake repo you use as source, the commit IDs change and projects using your repository as a submodule get an error about "unadvertised object"s.

As the title says I can't seem to figure out what the BUILD_SINGLE_CONTEXT/BUILD_MULTI_CONTEXT options actually do.
Furthermore, the target-properties OUTPUT_NAME do overlap for those targets, so in essence there is a race condition for the build whichever target finished building last wins and will write the final lib file, and hence the build result is indeterministic if both those options are active at the same time.

@Perlmint Can you please clarify what those are for. Thanks

Getting an error of no _DllMainCRTStartup function...

[1/2] Linking C shared library vendor\RAITOEngine\vendor\glew-cmake\bin\glew-sharedd.dll
FAILED: vendor/RAITOEngine/vendor/glew-cmake/bin/glew-sharedd.dll vendor/RAITOEngine/vendor/glew-cmake/lib/glew-sharedd.lib
C:\Windows\system32\cmd.exe /C "cd . && C:\PROGRA~1\LLVM\bin\clang.exe -nostartfiles -nostdlib -std=c2x -O0  -fuse-ld=lld-link -shared -o vendor\RAITOEngine\vendor\glew-cmake\bin\glew-sharedd.dll  -Xlinker /MANIFEST:EMBED -Xlinker /implib:vendor\RAITOEngine\vendor\glew-cmake\lib\glew-sharedd.lib -Xlinker /pdb:vendor\RAITOEngine\vendor\glew-cmake\bin\glew-sharedd.pdb -Xlinker /version:2.2 vendor/RAITOEngine/vendor/glew-cmake/CMakeFiles/libglew_shared.dir/src/glew.c.obj  -lopengl32.lib  -lkernel32 -luser32 -lgdi32 -lwinspool -lshell32 -lole32 -loleaut32 -luuid -lcomdlg32 -ladvapi32 -loldnames  && cd ."
lld-link: error: <root>: undefined symbol: _DllMainCRTStartup
clang: error: linker command failed with exit code 1 (use -v to see invocation)
ninja: build stopped: subcommand failed.

Any help would be appreciated...

When building on my older laptop (Ubuntu 18.04, cmake version 3.10.2, master branch), I got an error when linking my executable target:

[build] /usr/bin/ld: não foi possível localizar -lOPENGL_opengl_LIBRARY
[build] /usr/bin/ld: não foi possível localizar -lX11_X11_LIB
[build] /usr/bin/ld: não foi possível localizar -lX11_Xext_LIB

It is saying it can't find these libraries. I found out that was because these libraries are added as:

list(APPEND LIBRARIES OPENGL_opengl_LIBRARY)
list(APPEND LIBRARIES X11_X11_LIB X11_Xext_LIB)

Now, I only have being learning cmake recently, but I think these variables should be evaluated with ${}, since they aren't targets, am I right? I got it working correctly after changing them to:

list(APPEND LIBRARIES ${OPENGL_opengl_LIBRARY} )
list(APPEND LIBRARIES ${X11_X11_LIB} ${X11_Xext_LIB} )

I was following the instructions on how to build using cmake and got the following error

lib/libGLEW.so.2.2.0: error: undefined reference to 'glXGetProcAddressARB'

lib/libGLEW.so.2.2.0: error: undefined reference to 'glXGetClientString'

lib/libGLEW.so.2.2.0: error: undefined reference to 'glXQueryVersion'

CMakeFiles/visualinfo.dir/bin/glew-cmake/src/visualinfo.c.o:visualinfo.c:function CreateContext: error: undefined reference to 'glXQueryExtension'

CMakeFiles/visualinfo.dir/bin/glew-cmake/src/visualinfo.c.o:visualinfo.c:function CreateContext: error: undefined reference to 'glXChooseVisual'

CMakeFiles/visualinfo.dir/bin/glew-cmake/src/visualinfo.c.o:visualinfo.c:function CreateContext: error: undefined reference to 'glXCreateContext'

CMakeFiles/visualinfo.dir/bin/glew-cmake/src/visualinfo.c.o:visualinfo.c:function CreateContext: error: undefined reference to 'glXMakeCurrent'

CMakeFiles/visualinfo.dir/bin/glew-cmake/src/visualinfo.c.o:visualinfo.c:function DestroyContext: error: undefined reference to 'glXDestroyContext'

CMakeFiles/visualinfo.dir/bin/glew-cmake/src/visualinfo.c.o:visualinfo.c:function main: error: undefined reference to 'glXQueryExtensionsString'

collect2: error: ld returned 1 exit status

make[2]: *** [CMakeFiles/visualinfo.dir/build.make:94: bin/visualinfo] Error 1

make[1]: *** [CMakeFiles/Makefile2:110: CMakeFiles/visualinfo.dir/all] Error 2

make[1]: *** Waiting for unfinished jobs....

lib/libGLEW.so.2.2.0: error: undefined reference to 'glXGetProcAddressARB'

lib/libGLEW.so.2.2.0: error: undefined reference to 'glXGetClientString'

lib/libGLEW.so.2.2.0: error: undefined reference to 'glXQueryVersion'

CMakeFiles/glewinfo.dir/bin/glew-cmake/src/glewinfo.c.o:glewinfo.c:function glewCreateContext: error: undefined reference to 'glXQueryExtension'

CMakeFiles/glewinfo.dir/bin/glew-cmake/src/glewinfo.c.o:glewinfo.c:function glewCreateContext: error: undefined reference to 'glXCreateContext'

CMakeFiles/glewinfo.dir/bin/glew-cmake/src/glewinfo.c.o:glewinfo.c:function glewCreateContext: error: undefined reference to 'glXMakeCurrent'

CMakeFiles/glewinfo.dir/bin/glew-cmake/src/glewinfo.c.o:glewinfo.c:function glewCreateContext: error: undefined reference to 'glXMakeCurrent'

CMakeFiles/glewinfo.dir/bin/glew-cmake/src/glewinfo.c.o:glewinfo.c:function glewCreateContext: error: undefined reference to 'glXDestroyContext'

CMakeFiles/glewinfo.dir/bin/glew-cmake/src/glewinfo.c.o:glewinfo.c:function glewCreateContext: error: undefined reference to 'glXChooseVisual'

CMakeFiles/glewinfo.dir/bin/glew-cmake/src/glewinfo.c.o:glewinfo.c:function glewDestroyContext: error: undefined reference to 'glXDestroyContext'

collect2: error: ld returned 1 exit status

make[2]: *** [CMakeFiles/glewinfo.dir/build.make:94: bin/glewinfo] Error 1

make[1]: *** [CMakeFiles/Makefile2:137: CMakeFiles/glewinfo.dir/all] Error 2

sort of related to #38 but i checked against that and cmake version and system all seem to be fine

right now works on linux just not on windows (running in a github action)

cmake --version: 3.21.3

debug prints:

running: "git" "clone" "https://github.com/Perlmint/glew-cmake.git" "--recursive" "--branch" "glew-cmake-2.2.0" "D:\\a\\engine\\engine\\target\\_deps\\glew"
current_dir: "D:\\a\\engine\\engine\\target\\_deps\\glew\\build"
running: "cmake" "D:\\a\\engine\\engine\\target\\_deps\\glew" "-DCMAKE_BUILD_TYPE=Release" "-DCMAKE_INSTALL_PREFIX=D:\\a\\engine\\engine\\target\\_deps\\glew\\build\\install" "-Dglew-cmake_BUILD_SHARED=NO" "-DPKG_CONFIG_REPRESENTATIVE_TARGET=libglew_static" "-A" "x64"

actual error from command line:

CMake Error at GeneratePkgConfig.cmake:61 (install):
    install FILES given no DESTINATION!
Call Stack (most recent call first):
    CMakeLists.txt:129 (GeneratePkgConfigFile)

should i be calling the command differently between windows and linux?

thanks in advance @Perlmint ~

Hey, I'm trying to build GLEW with CMake in windows but it's try to include .rc files in the /build dir. Are these supposed to be generated at some point or am I missing something here?

cheers

I get the following errors when I try to link glew with my project:

make[2]: stat: vendor/glew-cmake/lib/libglew.a: Too many levels of symbolic links
make[2]: *** No rule to make target 'vendor/glew-cmake/lib/libglew.a', needed by 'Newton'.  Stop.
make[2]: *** Waiting for unfinished jobs....

checking the build dir:

/mnt/c/Users/sin3point14/github-clones/Newton/build$ ls -alh vendor/glew-cmake/lib
total 1.1M
drwxrwxrwx 1 sin3point14 sin3point14  512 Dec 30 03:19 .
drwxrwxrwx 1 sin3point14 sin3point14  512 Dec 30 03:18 ..
lrwxrwxrwx 1 sin3point14 sin3point14    9 Dec 30 03:19 libGLEW.a -> libglew.a
lrwxrwxrwx 1 sin3point14 sin3point14   23 Dec 30 03:19 libglew-shared.so -> libglew-shared.so.2.2.0
-rwxrwxrwx 1 sin3point14 sin3point14 1.1M Dec 30 03:19 libglew-shared.so.2.2.0

I am not exactly sure but I think this is because NTFS filesystems treat paths in a case insensitive manner.

cmake 3.19:

CMake Deprecation Warning at glew-cmake/CMakeLists.txt:1 (cmake_minimum_required):Compatibility with CMake < 2.8.12 will be removed from a future version of
CMake.

Update the VERSION argument <min> value or use a ...<max> suffix to tell
CMake that the project does not need compatibility with older versions.

There have been a few fixes this year upstream, but I don't see them flowing here yet.
Was it a victim of the Travis shutdown?

https://pastebin.com/1BZc3g0h

add this

https://github.com/Perlmint/glew-cmake/blob/master/config/version

by

#35

Seems like the update job hasn't run for a while.

The latest glew version is 2.1.0. Will you be able to pull and update this repo to 2.1.0? Thanks!

It makes the project seem badly out of date, since the tags denote GLEW releases.

You're cmakelists.txt is much different than the source project. I was thinking you should include basic compiling instructions in your readme.md. Or basic linking to project examples

Here is what I'm doing:
glew.cmake file:

include(FetchContent)
#options for FetchContent are at https://cmake.org/cmake/help/latest/module/ExternalProject.html
FetchContent_Declare(
        glew_fetch
        #GIT_REPOSITORY https://github.com/nigels-com/glew.git # do not reference this directly requires generating source fork does that for us.
        #GIT_TAG origin/master
        GIT_REPOSITORY https://github.com/Perlmint/glew-cmake.git
        GIT_TAG origin/master
        GIT_REMOTE_UPDATE_STRATEGY CHECKOUT
)
#FetchContent_MakeAvailable(glew)
FetchContent_GetProperties(glew_fetch)
if (NOT glew_fetch_POPULATED)
    FetchContent_Populate(glew_fetch)
    add_subdirectory(${glew_fetch_SOURCE_DIR} ${glew_fetch_BINARY_DIR} EXCLUDE_FROM_ALL)
endif ()

In our program I'm using target_link_libraries to link to PRIVATE libglew_static

There might be better ways. I've only been using cmake for about a year always learning new stuff. :D

hello, I created a glew project using cmake and it compiled a dynamic library. I need to use a static library. I write target_link_libraries(${PROJECT_NAME} PRIVATE libglew_static) in my project's CMakeLists.txt and the compiler says it can't find libglew_static.lib. I'm doing something wrong and I don't understand. Help please

The repo has changes which are not commited.
git clone https://github.com/omniavinco/glew-cmake.git GLEW
cd GLEW
git status
=>

On branch master
Your branch is up-to-date with 'origin/master'.

Changes not staged for commit:
  (use "git add <file>..." to update what will be committed)
  (use "git checkout -- <file>..." to discard changes in working directory)

    modified:   build/vc10/glew.sln
    modified:   build/vc10/glew_shared.vcxproj
    modified:   build/vc10/glew_static.vcxproj
    modified:   build/vc10/glewinfo.vcxproj
    modified:   build/vc10/visualinfo.vcxproj
    modified:   build/vc6/glew.dsw
    modified:   build/vc6/glew_shared.dsp
    modified:   build/vc6/glew_static.dsp
    modified:   build/vc6/glewinfo.dsp
    modified:   build/vc6/visualinfo.dsp

no changes added to commit (use "git add" and/or "git commit -a")

Please commit the changes to keep it clean.

The FindGLEW CMake module searches for libraries without a "lib" prefix. Also, when building for Windows, the module searches for static libraries with the ".lib" or ".dll.a" extensions.

I'm trying to use EGL on Linux and on linking it cannot find any of EGLEW symbols.
Are they only defined in the shared libraries ? Up to this point I only linked against GLEW's static libs...
Am I missing something there ?

[EDIT] After looking a bit more it seems there is no support for EGL, is there a reason for this ?

Some stuff like https://github.com/freedesktop/mesa-demos still relies on pkg-config to detect installed libs & headers so it would be useful if your CMake build could process & install the glew.pc.in file too.

Currently when building with with CMake 3.16.3 and above, the following warning is issued

Policy CMP0072 is not set: FindOpenGL prefers GLVND by default when
  available.  Run "cmake --help-policy CMP0072" for policy details.  Use the
  cmake_policy command to set the policy and suppress this warning.

  FindOpenGL found both a legacy GL library:

    OPENGL_gl_LIBRARY: /usr/lib/x86_64-linux-gnu/libGL.so

  and GLVND libraries for OpenGL and GLX:

    OPENGL_opengl_LIBRARY: /usr/lib/x86_64-linux-gnu/libOpenGL.so
    OPENGL_glx_LIBRARY: /usr/lib/x86_64-linux-gnu/libGLX.so

  OpenGL_GL_PREFERENCE has not been set to "GLVND" or "LEGACY", so for
  compatibility with CMake 3.10 and below the legacy GL library will be used.

I think this policy has to be set with cmake_policy(SET CMP0072 NEW)

https://circleci.com/docs/2.0/workflows/#section=jobs

https://docs.microsoft.com/ko-kr/azure/devops/pipelines/build/triggers?view=azure-devops&tabs=yaml#scheduled-triggers

For stability, move to circleCI or azure pipeline from self-hosted CI.

Why did all the releases download zip files omited CMakelists.txt?

It was just same like the official release. It has no CMake supports.

In relation to a pending issue upstream:
nigels-com/glew#235

It would be handy to trigger a (possible) update of Perlmint/glew-cmake when OpenGL-Registry is updated, or perhaps nightly or weekly to limit resource consumption.

I'm using as submodule in my project using CMAKE version 3.19.4. Get a warning about CMP0048.

Can a policy be set in glews CMakeLists.tx to supress this warning?
CMakeLists.txt

cmake_minimum_required(VERSION 2.8.12)

if (POLICY CMP0048)
cmake_policy(SET CMP0048 NEW)
endif()

project("glew")

When building the libglew_static target on tag glew-cmake-2.0.0 with mingw GCC 8.1.0 on windows 10 64bit the build fails. (glew-cmake having been added via FetchContent_Declare in CMake).

`[build] Starting build

[proc] Executing command: "C:\Program Files\CMake\bin\cmake.EXE" --build c:/Users/chris/Documents/dygd-bin/Development --config Development --target libglew_static -- -j 26

[build] [1/2 50% :: 63.107] Building C object _deps/glew-build/CMakeFiles/libglew_static.dir/src/glew.c.obj

[build] FAILED: _deps/glew-build/CMakeFiles/libglew_static.dir/src/glew.c.obj

[build] C:\ProgramData\chocolatey\lib\mingw\tools\install\mingw64\bin\gcc.exe -DGLEW_BUILD -DGLEW_NO_GLU -DVC_EXTRALEAN -DWIN32_MEAN_AND_LEAN -D_CRT_SECURE_NO_WARNINGS -I_deps/glew-src/include -O2 -g -MD -MT _deps/glew-build/CMakeFiles/libglew_static.dir/src/glew.c.obj -MF _deps\glew-build\CMakeFiles\libglew_static.dir\src\glew.c.obj.d -o _deps/glew-build/CMakeFiles/libglew_static.dir/src/glew.c.obj -c _deps/glew-src/src/glew.c

[build] In file included from _deps/glew-src/src/glew.c:33:

[build] _deps/glew-src/include/GL/glew.h:9883:118: error: unknown type name 'eglClientBufferEXT'; did you mean 'glClearBufferfi'?

[build] typedef void (GLAPIENTRY * PFNGLNAMEDBUFFERSTORAGEEXTERNALEXTPROC) (GLuint buffer, GLintptr offset, GLsizeiptr size, eglClientBufferEXT clientBuffer, GLbitfield flags);`

I'm trying to build on linux with travis or appveyor. Windows builds perfectly working but linux not fine.
-arch: linux/amd64
-dist: ubuntu 14.04
-codename: trusty

error lines:

CMake Error at deps/glew/CMakeLists.txt:135 (install):
  install TARGETS given no LIBRARY DESTINATION for shared library target
  "libglew_shared".

My CMakeList file: (just glew parts)

execute_process(COMMAND git submodule update --init WORKING_DIRECTORY ${CMAKE_SOURCE_DIR})
add_definitions(-DGLEW_STATIC)
add_subdirectory(${CMAKE_SOURCE_DIR}/deps/glew EXCLUDE_FROM_ALL)
target_link_libraries(${PROJECT_NAME} PRIVATE libglew_static)

travis script:

cmake -E make_directory Build
cmake -E chdir Build cmake .. //error is happening in this command
cd Build
make

I saw #17 but doesn't affect me.

Edit: Working on github actions. I do not know what should i say. yml file:

ubuntu:
    strategy:
      matrix:
        include:
          - compiler: gcc
            cxxcompiler: g++
    # The CMake configure and build commands are platform agnostic and should work equally
    # well on Windows or Mac.  You can convert this to a matrix build if you need
    # cross-platform coverage.
    # See: https://docs.github.com/en/free-pro-team@latest/actions/learn-github-actions/managing-complex-workflows#using-a-build-matrix
    runs-on: ubuntu-latest

    steps:
    - uses: actions/checkout@v2
      with:
          submodules: true
    - name: install packages and build
      shell: bash
      run: |
        sudo apt-get install cmake libxrandr-dev libxinerama-dev libxcursor-dev libxi-dev libgl1-mesa-dev
        cmake -BBuild -G "Unix Makefiles"
        cd Build
        make

After one of the commits regarding symlinks, the library seems to no longer compile on macOS. This Github Action run was performed on commit 7d525405e6abd0933f1a44c066645caea805f5d5 (before symlinks where intoduced). It compiles fine on Ubuntu and on macOS. On the other hand, this run uses the most recent commit and fails. The errors are:

[  9%] Linking C static library lib/libglew.a
create libGLEW symbolic link
make[3]: stat: external/glew-cmake/lib/libglew.a: Too many levels of symbolic links
[  9%] Built target libglew_static

and

Scanning dependencies of target glfwpp_example_basic
[ 86%] Building CXX object examples/CMakeFiles/glfwpp_example_basic.dir/basic.cpp.o
make[3]: stat: external/glew-cmake/lib/libglew.a: Too many levels of symbolic links
make[3]: *** No rule to make target `external/glew-cmake/lib/libglew.a', needed by `examples/glfwpp_example_basic'.  Stop.

It seems that one of the commits regarding symlinks broke something, though it's hard for me to tell which one.