Set up cmake on the mac

solin edited this page Mar 5, 2011 · 2 revisions

These instructions come from Gerhard Hoffmann (TU Darmstadt)

(They are copied and pasted from an email, so you may prefer to read the source code of the wiki.)

Let's go back to CMAKE. Step 1 is done. We have a i386 installation running, so we can relax. The solution is there, all we have to do is to make it managable in CMake. It is as if we'd proven a theorem, but the proof is a bit messy, and we have to beautify it for some paper. (With 'we' I mean 'you', Colman :))

I will tell you the first step again.

Once logged in to mateusz's machine, check out the newest version in a clean directory, /Users/gerhard/colman, say.

The toplevel directory is then /Users/gerhard/colman/hermes Under this directory you generate a directory called build.


After setting the environment variables for Cython, change to /Users/gerhard/colman/hermes/build. From here you call cmake, i.e. you do: 'cmake ../'

Cmake will use the CMakeLists.txt file in the top level hermes directory. The advantage is, that all the CMake generated files will be under ./build. The top level directory ./hermes will be unaffected by CMake. This helps later when you have to look for the CMake-generated files. So you have two terminals open: one to call 'cmake ../', and the other one exploring the contents of ./hermes.

Now we have to change CMakeLists.txt in the top level directory ./hermes.

You add the following lines after



uncomment this line to see the compile/link commands executed by CMAKE


IF (APPLE) ## compiling for OSX only in i386 format. Library with the ## necessary symbol '_glutSetOption' was only available ## in /usr/lib/libglut.dylib, which happened to be a pure ## i386 library. Maybe fixed later. SET(CMAKE_OSX_ARCHITECTURES "i386" CACHE STRING "" FORCE) MESSAGE(STATUS "COMPILING FOR OSX, i386 platform") MESSAGE(STATUS "CMAKE_HOST_SYSTEM_VERSION ..... = ${CMAKE_HOST_SYSTEM_VERSION}") MESSAGE(STATUS "CMAKE_HOST_SYSTEM_NAME ........ = ${CMAKE_HOST_SYSTEM_NAME}") MESSAGE(STATUS "CMAKE_HOST_SYSTEM_PROCESSOR ... = ${CMAKE_HOST_SYSTEM_PROCESSOR}") ENDIF (APPLE)

Note that this MESSAGE command is basically the only tool to debug what CMake is actually doing. So use it, please. It is the same as printf-debugging in C.

Save CMakeLists.txt and change to ./build. Call 'cmake ../'

You should see this the messages on your screen. You don't have to compile, it would not work in this stage.

Once this is done, you can check in the top level CMakeLists.txt. Keep in mind, you are the only one working on the Mac at the moment. Other users will not affected by you code as long as it stays behind the 'IF (APPLE)' check.

And now starts the difficult part. The symbol _glutSetOption is in /usr/lib/libglut.dylib. But other users might not have it, like yourself on your MacMini. You have to tell them. Technically, you have to extend the finder FindGLUT.cmake.

You can see it under ./Applications/CMake or /opt/local/share/cmake-2.8/Modules/FindGLUT.cmake

It is a standard finder developed by the CMake team. You don't have to write a finder now (use your CMake book to find out what that exactly is), but you have to know what library names the finder will give you.

The GLUT package is loaded by a command like

find_package(GLUT REQUIRED)

in one of the CMakeLists.txt files. Look for it.

(You can also load it by INCLUDE(FindGLUT) provided Cmake knows the include path, but that's usually not necessary.)

CMake uses the MODULE_PATH to look up FindGLUT.cmake and executes the commands contained in FindGLUT.cmake.

After that you have to find out if one of the libraries the finder has found does contain _glutSetOption. If not, stop the cmake configuration.

How do you do this? Well, that's your job now. Basically you can execute the same command from CMake as in the shell. Look for execute_program (or similar stuff) in CMake and how to use it.

In the shell, you would write

nm /usr/lib/libglut.dylib | grep _glutSetOption

with the output

00010820 T _glutSetOption

You have to look for the 'T'. This means defined. So if the end of the string returned by grep is 'T _glutSetOption' you can continue.

With execute_program you can do the same thing from inside CMake.

You can make your experiments from inside the top level CMakeLists.txt. But don't check it in, there might be a better place where to put the final test (you will see once you get more accustomed with the structure of Pavel's project).

After this test is working, you have found where to put it and checked it in, its time to integrate the remaining libs into cmake.

For example, you have noticed that we extended the link.txt file under hermes2d-cplx-debug.dir, i.e. hermes2d-cplx-debug.dir/link.txt

(this is generated by CMake, so you will find the original thing in the ./build directory)

by the libraries:

libGLU.1.3.dylib libOSMesa.7.2.dylib

You have to make sure that these libs show up in hermes2d-cplx-debug.dir/link.txt (under the build directory) after you have called 'cmake ../' from inside the build direcory.

How to do this? Well, one possiblity is to use these to finders:

FindOpenGL.cmake FindGLU.cmake

They might do the job already. If not, you have to write your own finder, I think. And you have to tell cmake to use the libs: use the cmake variable 'link_directories', something like that.

This step is done when all the CMake generated 'link.txt' files under hermes2d-cplx-debug.dir, hermes3d-real-debug.dir, etc. look like these files (in ~/files-to-copy) hermes2d-cplx-debug.dir-link.txt hermes3d-real-debug.dir-link.txt hermes2d-cplx.dir-link.txt hermes_common-cplx-debug.dir-link.txt hermes2d-real-debug.dir-link.txt hermes_common-cplx.dir-link.txt hermes2d-real-link.txt hermes_common-real-debug.dir-link.txt hermes3d-cplx-debug.dir-link.txt hermes_common-real.dir-link.txt

Another step: I have created a file named


You can see it contains a list of paths to link.txt files.

There is an script as well.

Calling ' list.txt'

will do the following. In all those link.txt files (they are generated by CMake, so in your case they will be under ./build), it replaces /usr/lib/libGLEW.dylib with /opt/local/lib/libGLEW.dylib.

Your task: Make sure CMake generates those link.txt files with /opt/local/lib/libGLEW.dylib instead /usr/lib/libGLEW.dylib.

Last step: we have to export the following variables before the compile step: export CPLUS_INCLUDE_PATH=/usr/include export C_INCLUDE_PATH=/usr/include

This is clumsy. Your task: change the CMake configuration, such that we don't have to do this.

If all this is done, go to the build-directory, uncomment SET(CMAKE_VERBOSE_MAKEFILE true CACHE BOOL "" FORCE) in ../CMakeLists.txt to see what's going on and execute 'cmake ../' followed by 'make'.

The compilation should succeed now. Call 'make test'.

If all goes well, and it certainly will do, then check in all your changes.

I have to work on my own stuff now (Sascha will kill me anyways :)), so it's really your party now. Enjoy and good luck!

And bye Pavel. We are really happy we are able to help you.

Cheers Gerhard