Open OleksiiMomot opened 10 years ago
The sources are available via the GLEW homepage, either the 1.10.0 release, or the more recent snapshots. http://glew.sourceforge.net/
You have to go into the auto folder and make there first.
thanks, thecodethinker! nigels-com, can you update the README to reflect this requirement?
top-level make produces this error in OSX 10.9:
make: *\ No rule to make target src/glew.c', needed by
tmp/darwin/default/shared/glew.o'. Stop.
Generating the source code is discussed here: http://glew.sourceforge.net/advanced.html
I'd welcome patches to the README, of course.
@nigels-com If you want, you could add this to build/cmake/CMakeLists.txt
add_custom_command(
OUTPUT ${PROJECT_SOURCE_DIR}/../../src/glew.c ${PROJECT_SOURCE_DIR}/../../src/glewinfo.c
WORKING_DIRECTORY ${PROJECT_SOURCE_DIR}/../../auto
COMMAND ${CMAKE_MAKE_PROGRAM}
)
This way, it will invoke make in the auto folder only if glew.c and/or glewinfo.c are missing.
That's an interesting idea, but it's likely to fail on Windows, right?
I just tried on my Windows VM with MinGW. It works fine. I had to add C:\Program Files (x86)\Git\bin;C:\MinGW\bin
to my %PATH% in order to be able to build with MinGW
here's what I did:
git clone git@github.com:nigels-com/glew.git
glew/build/cmake/CMakeLists.txt
add_custom_command(
OUTPUT ${PROJECT_SOURCE_DIR}/../../src/glew.c ${PROJECT_SOURCE_DIR}/../../src/glewinfo.c
WORKING_DIRECTORY ${PROJECT_SOURCE_DIR}/../../auto
COMMAND ${CMAKE_MAKE_PROGRAM}
)
mkdir glew-build
cd glew-build
cmake -G "Unix Makefiles" ../glew/build/cmake
make
And it worked! here's the output:
winbuild@winbuild-win7 /c/Users/winbuild/glew-build
$ make
[ 9%] Generating C;C:\MinGW\msys\1.0\Users\winbuild\glew\build\cmake\..\..\src\
glew.c, C;C:\MinGW\msys\1.0\Users\winbuild\glew\build\cmake\..\..\src\glewinfo.c
--------------------------------------------------------------------
Downloading registry
--------------------------------------------------------------------
Cloning into 'registry'...
remote: Counting objects: 10618, done.
remote: Total 10618 (delta 0), reused 0 (delta 0), pack-reused 10618 eceiving ob
Receiving objects: 100% (10618/10618), 12.39 MiB | 848.00 KiB/s, done.
Resolving deltas: 100% (8681/8681), done.
Checking out files: 100% (1777/1777), done.
--------------------------------------------------------------------
Creating descriptors
--------------------------------------------------------------------
Hexadecimal number > 0xffffffff non-portable at bin/parse_spec.pl line 353.
Hexadecimal number > 0xffffffff non-portable at bin/parse_spec.pl line 357.
...
--------------------------------------------------------------------
Creating glew.h
--------------------------------------------------------------------
no keys in table!
no keys in table!
...
--------------------------------------------------------------------
Creating wglew.h
--------------------------------------------------------------------
no keys in table!
no keys in table!
...
--------------------------------------------------------------------
Creating glxew.h
--------------------------------------------------------------------
no keys in table!
no keys in table!
...
--------------------------------------------------------------------
Creating glew.c
--------------------------------------------------------------------
Use of uninitialized value in length at bin/make_list.pl line 47.
--------------------------------------------------------------------
Creating glewinfo.c
--------------------------------------------------------------------
--------------------------------------------------------------------
Creating glew.html
--------------------------------------------------------------------
--------------------------------------------------------------------
Creating wglew.html
--------------------------------------------------------------------
--------------------------------------------------------------------
Creating glxew.html
--------------------------------------------------------------------
Scanning dependencies of target glew
[ 18%] Building C object CMakeFiles/glew.dir/__/__/src/glew.obj
Linking C shared library bin/glew32.dll
[ 18%] Built target glew
Scanning dependencies of target glew_s
[ 27%] Building C object CMakeFiles/glew_s.dir/__/__/src/glew.obj
Linking C static library lib/libglew32.a
[ 36%] Built target glew_s
Scanning dependencies of target glewinfo
[ 45%] Building C object CMakeFiles/glewinfo.dir/__/__/src/glewinfo.obj
Linking C executable bin/glewinfo.exe
[ 54%] Built target glewinfo
Scanning dependencies of target glewmx
[ 63%] Building C object CMakeFiles/glewmx.dir/__/__/src/glew.obj
Linking C shared library bin/glew32mx.dll
[ 72%] Built target glewmx
Scanning dependencies of target glewmx_s
[ 81%] Building C object CMakeFiles/glewmx_s.dir/__/__/src/glew.obj
Linking C static library lib/libglew32mx.a
[ 90%] Built target glewmx_s
Scanning dependencies of target visualinfo
[100%] Building C object CMakeFiles/visualinfo.dir/C_/Users/winbuild/glew/src/visualinfo.obj
Linking C executable bin/visualinfo.exe
[100%] Built target visualinfo
That is impressive indeed. Time to update the instructions, I think!
Glad I could help.
This does not seem to have ever happened? I was running into this until I found this issue.
Could we actually get this added? I'd be happy to do so if @nigels-com or @mchiasson does not have the time.
I concur. I hit the same problem on 1.13.0 just now.
There is currently no plan to put the generated sources in revision control. See the related issue for some of the reasons. https://github.com/nigels-com/glew/issues/31
@nigels-com I'm not asking for the generated sources to be added to the revision control, just that the cmake addition that @mchiasson created be added. This, and a change to the README, would make compiling this massively easier for people who are new to the project or have never compiled it before.
Ah, the thin layer over the make file. For Linux and Mac ONLY?
The downside is that source generation can fail due to upstream changes in the OpenGL extension specifications. I don't want an angry bug report every time that happens, it's pretty much to be expected. There are good reasons I steer folks to the pre-built (and tested) releases.
New to Glew - Please at least add this to the README. Compiling glew without this information is frustrating to say the least.
It still hasn't been added to the README. It's a small change that would make life easier for anyone new to the project just trying to clone the repo.
If it's possible to steer folks away from building from scratch, that would be much better, from a maintainer's point of view. There are carefully vetted and tested releases for a good reason, use those, please.
Yes, i agree. But then i think it should be explicitly said somewhere. I think the text in the website "An up-to-date copy is also available using git: " suggests it's very much ok to download from git as a user. Unless I'm missing something?
(As a personal anecdote, I am inserted in a CG class and A LOT of people tried (some succeeded some didn't) to build the project from scratch.)
Is there any way to get full source (and/or prebuild libs) for windows with help of some script? I'd like to add CI to my project which is using GLEW, but i don't want to include generated glew sources directly in my project source. I also don't have direct access to build server, so I can't just copy already downloaded files there. I can do it only by calling some utility from cmd or powershell script.
For fetching full source, I'd suggest the following script:
wget https://github.com/nigels-com/glew/releases/download/glew-2.0.0/glew-2.0.0.zip
And for Windows binaries:
wget https://github.com/nigels-com/glew/releases/download/glew-2.0.0/glew-2.0.0-win32.zip
Thanks
Hello to every one glew developers and users.
most of GLEW is generated by perl scripts. >>
What is your thoughts if CMake will be do that? It also have regex, no so powerful like in perl, but on initial stage it seems that can be usability. My strategy of creating cmake script is next: I have two repository with glew and glfixes that checkouted to 1.13.0 label. The task is to generate structure like it in the glew-1.13.0 snapshot - just missed at repository files. By the way, why glfixes is not a git submodule of glew repository?
For now active stage of creation CMake file is on pause. Even custom.txt processing not finish: I do not recognize what of algorithm to create from one extension from glfixes to several extenation placed in one auto folder at glew >>. I publish the current snapshot of such work because maybe some one too experiments on this theme.
Personally for projects in what I use glew I use modifier variant of @mchiasson - just direct call of make tool:
# file(READ "${CMAKE_BINARY_DIR}/glew/build/cmake/CMakeLists.txt" file_content)
# string(FIND "${file_content}" "add_custom_command" pos)
# if("${pos}" EQUAL -1)
# set(ADDITION_COMMAND "add_custom_command(\n OUTPUT \${CMAKE_BINARY_DIR}/glew/src/glew.c \${CMAKE_BINARY_DIR}/glew/src/glewinfo.c\n WORKING_DIRECTORY .\n COMMAND \${CMAKE_MAKE_PROGRAM}\n)\n")
# set(file_content "${file_content}\n\n${ADDITION_COMMAND}\n")
# message("Write ${CMAKE_BINARY_DIR}/glew/build/cmake/CMakeLists.txt")
# file(WRITE "${CMAKE_BINARY_DIR}/glew/build/cmake/CMakeLists.txt" "${file_content}")
# endif()
# add_subdirectory("${CMAKE_BINARY_DIR}/glew/build/cmake" "${CMAKE_BINARY_DIR}/glew/build/cmake")
execute_process(COMMAND ${CMAKE_MAKE_PROGRAM} -C "${CMAKE_BINARY_DIR}/glew/auto")
set(glew_Path ${CMAKE_BINARY_DIR}/glew)
To structure early created by next CMake code:
if(NOT EXISTS "${CMAKE_BINARY_DIR}/glew")
message("Copying ${glew_Path} into ${CMAKE_BINARY_DIR}/glew")
execute_process(COMMAND ${CMAKE_COMMAND} -E copy_directory "${glew_Path}" "${CMAKE_BINARY_DIR}/glew")
endif()
set(REQUIRED_TO_WRITE FALSE)
file(READ "${CMAKE_BINARY_DIR}/glew/auto/Makefile" file_content)
string(FIND "${file_content}" "\$(GIT_CLONE)" pos)
if("${pos}" EQUAL -1)
else()
string(REPLACE "\$(GIT_CLONE)" "# \$(G_I_T_CLONE)" file_content "${file_content}")
set(REQUIRED_TO_WRITE TRUE)
endif()
string(FIND "${file_content}" "GIT_CLONE" pos)
if("${pos}" EQUAL -1)
else()
string(REPLACE "GIT_CLONE" "# G_I_T_CLONE" file_content "${file_content}")
set(REQUIRED_TO_WRITE TRUE)
endif()
if(REQUIRED_TO_WRITE)
message("Write ${CMAKE_BINARY_DIR}/glew/auto/Makefile")
file(WRITE "${CMAKE_BINARY_DIR}/glew/auto/Makefile" "${file_content}")
endif()
if(NOT EXISTS "${CMAKE_BINARY_DIR}/glew/auto/registry")
message("Copying ${glfixes_Path} into ${CMAKE_BINARY_DIR}/glew/auto/registry")
execute_process(COMMAND ${CMAKE_COMMAND} -E copy_directory "${glfixes_Path}" "${CMAKE_BINARY_DIR}/glew/auto/registry")
endif()
But only for Linux systems. On Windows it steal used snapshot.
With respect, user of glew library.
Hello.
In my previous message in this thread I propose generate missed source files by CMake. Well, regex engine that have last one not so power like have perl. So I implemented such 'generator' by using C++ 11 (support to build at Visual Studio 2013 and gcc 5.4).
Idea next – all users of library that have C++ 11 compiler can generate missed source automatic, in case of Visual Studio before first run.
What about generated source C files (glew.c, glewinfo.c, ..)? Well mostly different that spaces, but sometimes alternative implementation (C++11, reference – that is exists make/perl/python) get even more for some of glew version, for example some tokens at egl head file (sRGB for example, exist regex at perl script probably missed in order to small register char ‘s’). Also some missed name string get by this implementation, for example such that have (legacy) (some of file from glfixes have such) at one line at specification.
That implementation can be used to improve exists now – for example:
Implementation used perl script as data source and internally execute bash script on data in list
No addition libraries required, however for developing purpose you can connect pugixml as xml back end. Honestly dev branch, that not uploaded at gist, totally based on that library together with google test.
In Debug mode pugixml much more performance than internal implementation, but for Release I choose no addition dependence as original propose - only C++ 11 compiler.
Thank you for your attention.
Update 2019.01.22: After apply advice from @zeux output between internal 'xml back end' and external xml library pugixml is same.
Update 2019.05.06: Internal xml 'reader' got addition changes so at Debug it also usable from performance perspective, different with pugixml no such huge like early.
Currently in master
branch both GLX and WGL are now generated via the Python path, rather than Perl. That leaves GL as the last piece of code generation in Perl. So, while the progress is slow, that's the intended direction of things. I'm not sure how much there is to do to be 100% Python, but I do think there are a bunch of little fixups to match what the Perl is producing.
You have to go into the auto folder and make there first.
Man.... if this was added to the README page that would be nice. Should I make a PR ? Imagine though that this is such a popular question, then better documentation is required!
8(