Menu
▾
▴
#278 CMakeLists.txt missing with 1.13.0
With glew 1.13, CMakeLists.txt is missing, both in src/tgz packages and in git repo. It existed in glew 1.12. Please distribute a CMake build script, as it makes incorporating and automatic building of your library in my libraries and programs much easier. As soon as we require the latest graphics support, we cannot depend on OS distribution and thus need to build it manually. I think many others wil appreciate it as well. Thanks for your support. Regards, Benjamin.
I think this was moved to build/cmake
View and moderate all "bugs Discussion" comments posted by this user
Mark all as spam, and block user from posting to "Bugs"
Hi. I see. I just tried building glew (git repos, master at cbd0dce3c59c9a9fa35d2d2b20a697acb1ed6a67).
CMake Error at CMakeLists.txt:46 (add_library):
Cannot find source file:
Tried extensions .c .C .c++ .cc .cpp .cxx .m .M .mm .h .hh .h++ .hm .hpp
.hxx .in .txx
Directly including glew into other higher level cmake based projects resulted in problems. Reason: Cmake did not discovered CMakeLists.txt. By convention: CMakeLists.txt should be in the root directory of a library project to make life for other programmers easier.
Can you explain me why CMakeLists.txt is now located in /build/cmake? I guess the reason I haven't found it before is just because it is not easy to discover. I really don't want to search entire project trees (dependencies) for such a cmake file. This way, I can't use 1.13. Why is it not the way as in 1.12 which did work?
Please correct me if I am wrong, but as I understand it, cmake is an abstraction for building c/c++ projects. You do can create projects for make, VC or what ever is out there, depending on OS and other local user configs. If this is the case, why are there project directories for visual studio? Is in the end, there is a high level build script (cmake) in /build, in which there are low level build scripts as well (windows), and in the root directory is also a low level build script (linux). Why different places?
Anyway, many thanks for your quick reply and for this library. Normally it works pretty well. It's just that integrating glew as dependencies in project (for in project builds) is not comfortable anymore as compared to 1.12.
The cmake support in GLEW is still currently experimental, and I moved it out of the root directory to avoid confusion with the long-established (and better supported) GNU make build system. I have some reluctance to switch over to cmake as the primary toolchain, although I have an open mind on that. The reason that your build is failing is probably due to skipping the code generation step, which I don't think is incorporated into the cmake build yet. It's recommended to use an official release source archive, rather than git master branch.
View and moderate all "bugs Discussion" comments posted by this user
Mark all as spam, and block user from posting to "Bugs"
I agree to use an official release source archive (or at least a git tag) rather than a git master branch.
My point is that it did work until 1.12.0. And I don't expect it to work less in this respect with a successor release. You can easily tell cmake to extract an archive, build it and use it as dependency (include + lib).
"The reason that your build is failing is probably due to skipping the code generation step". Exactly. The reason is just because CMake can not find CMakeLists.txt in the root directory, and moving it into some sub directory (e.g. build/ which is not considered to be good practice because it directly resides in the build directory) practically now renders this build script totally useless because it does not work anymore because of incorrect paths because the way it is written. You should go top-down (from root to child directories), not go a few levels to the top (the root), and then somewhere down to the source.
It does not work anymore this way.
And yes, Makefile is pretty stable because it is old. Its not the way we develop cross-os software these days. It's old fashioned. More and more people are using cmake - for a very good reason.
I just hope you will provide a simple cmake build script.
Don't misunderstand. I'm aware of the popularity of cmake. Actually I'm somewhat of an advocate of cmake. However, cmake isn't a perfect fit for GLEW. Let me explain. The GLEW makefiles are not merely concerned with compiling source code into binaries. The GLEW project is more concerned with "code generation" - fetching extension specifications (wget), parsing them (perl) and generating the glew.c and glew.h files (make/perl/sed). It isn't the most slick or modern implementation (I dislike perl, for example) but that's what is entrenched and unfortunately it's a bit fragile on Windows.
I can understand from an end-user perspective that the "old makefile cruft" just ought to be replaced with CMakeLists.txt. But you if dig into the details you'd realise that a lot of the code generation (creating glew.c etc) is currently implemented using GNU make.
The thing that makes cmake a bit hostile to GLEW is that overwrites makefiles, and isn't so suitable for the more general GLEW workflow. And you're insistant that the build directory is repurposed according to cmake conventions? Until just recently I didn't have a Windows machine to even test the build.
The cmake build can certainly be further improved. GLEW is "old fashioned" because it's an old project. Also, it's in wide deployment and changes can result in widespread disruption. "It works for me on my chosen OS" isn't sufficient in this context.
Closing this as a "won't-fix" due to my concerns about cmake overwriting the existing (and necessary) hand-coded Makefile. I made a small increment towards shifting the GLEW code generation from perl to python+XML, but we're a long way from retiring the GNU makefile.
I do appreciate the feedback, but the time I spend on GLEW is a scarce resource, IMHO.