Hacker News Reader

Comment by angersock | Hacker News Reader

CMake Error at CMakeLists.txt:20 (find_package): By not providing "FindGLEW.cmake" in CMAKE_MODULE_PATH this project has asked CMake to find a package configuration file provided by "GLEW", but CMake did not find one.

  Could not find a package configuration file provided by "GLEW" with any of
  the following names:

    GLEWConfig.cmake
    glew-config.cmake

  Add the installation prefix of "GLEW" to CMAKE_PREFIX_PATH or set
  "GLEW_DIR" to a directory containing one of the above files.  If "GLEW"
  provides a separate development package or SDK, be sure it has been
  installed.

-- Configuring incomplete, errors occurred!

(Linux 3.2.0-4-amd64 #1 SMP Debian 3.2.51-1 x86_64 GNU/Linux)

View on HN

Welcome to the pile of busted that is CMake. If you do it for a living, you'll even get to learn their wonderful psuedo language, so you can parse through 450 lines of Find*.cmake just to figure out that all it does is check ENV_VAR0 and then fall back to a hardcoded string- even though the documentation/header claims it checks ENV_VAR1.

This.

CMake is another barrier to entry.

what happened to a nice simple makefile? Been using just standard makefiles for literally 20 years.

The only thing I do is put a checkdeps dependency on which tests for the presence of dependencies, like autoconf but without the eye poking. Have built everything from small network servers to Motif behemoths doing only that.

You get no (compatible) make on MSVC. More imporantly, whith nontrivial dependencies to third party libraries, self-coded makefiles just break down. Cross-platform handling of dependencies is fragile and makes drudgery. You're liable to do worse than CMake - after wasting a lot of time and energy.

CMake is more an alternative to GNU autoconf and pals, with the difference that it has first class support for things like MSVC and XCode.

I don't build for windows so that's moot for me. Well I do but not C.

I've quite happily built makefiles that work on Linux, FreeBSD, Solaris and HP/UX that aren't fragile or laborious. It just takes appropriate knowledge of the platforms. I've built some stuff on OSX (small SDL project) and it wasn't too obtuse apart from some paths.

CMake, much as all of these things, works up to a point at which point it tries desperately to kill you at every available opportunity.

Is nmake not compatible with make? I thought that it was. I haven't programmed C/C++ on Windows at all though, so I have no experience with this.

Microsoft "nmake" is unrelated to the AT&T-originated Unix "nmake", which you may be thinking of.

(people rarely even attempt nontrivial Makefiles that are portable between BSD and GNU makes though...)

Not really- that, and it is incredibly feature poor.

Whenever I see a project with CMake it generally puts me off as I know it's liable to require some intervention from me to get it just building.

It drove me crazy when I realized that CMake "achieves" being cross-platform by having you write tons of IF/ELSE conditions for every single platform you decide to support. My (naive?) understanding of cross platform was that it would abstract away most of those platform specific details.

That's what I thought when we tried to move one of our projects to CMake. By the second platform, we'd given up.

Not only that, some of it doesn't actually work properly and it refuses to compile itself on HPUX.

That's pretty much the same for GNU autotools, by the way.

Beyond the common platforms (linux, freebsd and sometimes cygwin), autotools break regularly, because they are not tested as well as on linux. Macros provided by libraries are even more prone to these issues.

I remember I had huge issues on IRIX to make even simple projects compile, so much that "irixfreeware" had an unsupported/patched automake that fixed some of these issues if you could have the luxury of re-generating the configure. Add to that that autotools broke backward compatibility of the configure.in scripts very often, and this is why debian has all versions of automake starting from 1.4 coexisting in the repository, and my patched automake was next to useless.

CMake is generally less painful if you learn it a bit. For the same level of underlying knowledge, CMake is way easier to "fix" when the build breaks, because it's a single tool, with an API which is quite consistent and doesn't involve a lot of magic. Fixing a configure failure with automake is hell by comparison. Fixing a Make failure with automake is also harder.

That being said, I generally dislike CMake. The syntax is just horrible (did they actually try to copy automake here?). The build system is still convoluted, and the output is basically unmodifiable. It doesn't "help" you much in porting to other operating systems either, really, like you say.

For some people, CMake just provides a convenient way to build the software by exporting a VS project file. I would never recommend to export Xcode projects by contrast, since you can just as well use the normal Makefile approach on OSX.

Writing correct tests for feature discovery in automake is very hard. I cannot count the times some tests fail to properly detect an include/library/path because of a different compiler version and/or because the script writer tried to mess with CFLAGS/LDFLAGS. The same in CMake is saner on that front, at least.

But did I already say I don't like CMake?

> Fixing a configure failure with automake is hell by comparison.

autotools. never again.

I had the fortunate pleasure of fixing a package on CentOS. The program needed to copy/write files in /tmp and back which meant configuring and compiling SELinux policies. This was such a pain in the ass to get working in autotools.

Cmake is a breeze by comparison.

CMake abstracts the generation of platform specific files like Xcode projects, makefiles and Visual Studio projects. This does not mean that you have to write tons if-defs.

galaktor isn't talking about #ifdefs, galaktor is talking about CMake-language special casing.

I was going to contribute a VS2012 and VS2008 project, but honestly I saw CMake and just kind of groaned.

FindGLEW.cmake is a standard CMake module from v2.8.10. Previous versions do not have this file thus cannot build the project. You can install a newer version of CMake or get this file from CMake git repo and copy it to /usr/share/cmake-2.8/Modules/

On ubuntu 13, I had to

  sudo apt-get install cmake libglew-dev xorg-dev

The readme mentions this, too:

  sudo apt-get build-dep glfw

Right, did all that. ;)

The last step yields:

  Reading package lists... Done
  Building dependency tree       
  Reading state information... Done
  E: You must put some 'source' URIs in your sources.list

Debian (#!) over here.

EDIT:

Even after updating my /etc/apt/sources.list, and having the build-dep step run without error, I still get that original message. :(

Try compiling cmake yourself from the latest source at: http://www.cmake.org/cmake/resources/software.html

I was having the same issue on Ubuntu until I uninstalled cmake and compiled from source.

It builds and runs fine on current Debian testing.

Compiles out of the box on Slackware 14.1 64 bit. I had to run cmake in "wizard mode" (cmake -i), I kept all the defaults except changing to lib64.

Reply on news.ycombinator.com