Joachim Reichel
Fernando Cacciola
The goal of the CGAL, the Computational Geometry Algorithms Library Open Source Project, is to provide easy access to efficient and reliable geometric algorithms in the form of a C++ library.
This document describes how to install CGAL on Windows, Unix-like systems and MacOS X.
Ideally, the installation reduces to
cd CGAL-3.4 # go to CGAL directory cmake . # configure CGAL make # build the CGAL libraries cd examples/Straight_skeleton_2 # go to an example directory cmake -DCGAL_DIR=$HOME/CGAL-3.4 . # configure the examples make # build the examples
In a less ideal world, you probably have to install CMake, a makefile generator, and third party libraries. That's what this manual is about.
The focus of the CGAL project is on geometry, and we rely on other highly specialized libraries and software for non-geometric issues, e.g. for numeric solvers, or visualization.
In order to build the CGAL libraries you need a C++ compiler. CGAL 3.4 is supported for the following compilers/operating systems:
compiler | operating system |
GNU g++ 4.0, 4.1, 4.2, 4.3 10 | Solaris 2.6+ / Linux 2.x / MacOS X |
MS Windows 95/98/2000/XP/NT411 | |
MS Visual C++ 8.0, 9.0 (VISUAL STUDIO 2005 AND 2008) 12 | MS Windows 95/98/2000/XP/NT4/Vista11 |
Note that neither prerelease versions nor repository snapshots of GCC are supported.
In order to configure, build and install the CGAL libraries, as well as the examples and demos, you need CMake, a cross-platform ``makefile generator''. If CMake is not installed already you can obtain it from http://www.cmake.org/. We recommend the usage of CMake release 2.6, and you need at least CMake release 2.4-patch-7.
Some demos depend on Boost.Program_options.
CGAL combines floating point arithmetic with exact arithmetic, in order to be fast and reliable. CGAL offers support for GMP+MPFR and LEDA exact number types, as well as a built-in exact number type used when none of the other two is installed on your system.
Having GMP version 4.1.4 or later and MPFR version 2.2.1 or later installed is highly recommended. These libraries can be obtained from http://gmplib.org/ and http://www.mpfr.org/, respectively, if they should not be present on your system. As Visual C++ is not properly support by the GMP and MPFR projects, we provide precompiled versions of GMP and MPFR.
LEDA can be found at http://www.algorithmic-solutions.com/leda/index.html. There is a free and a commercial edition for this library.
Most demos use Trolltech's cross-plaform GUI toolkits Qt3 or Qt4. In case Qt is not yet installed on your system, you can download it from http://www.trolltech.com.
Some 3D demos use the libQGLViewer, which is a 3D widget for Qt4. It can be downloaded from http://www.libqglviewer.com
The Surface Mesh Generator demo can read compressed image files if zlib is installed. It can be downloaded from http://www.zlib.net.
The Approximation of Ridges and Umbilics on Triangulated Surface Meshes package as well as the Estimation of Local Differential Properties package depends on the BLAS and LAPACK libraries. Implementations can be found at http://www.netlib.org/blas/ and http://www.netlib.org/lapack/. We provides precompiled versions of BLAS and LAPACK for Visual C++.
The Surface parametrization package can be speeded up by using the sparse matrix solver TAUCS. This library can be downloaded from http://www.tau.ac.il/~stoledo/taucs/. As Visual C++ is not properly supported by the TAUCS project, we provide a precompiled version of TAUCS.
The CGAL library can be downloaded from http://www.cgal.org/download.html.
After you have downloaded the file CGAL-3.4.tar.gz containing the CGAL library, you have to unpack it. Under a Unix-like shell, use the command
tar xzf CGAL-3.4.tar.gz
When you are on Windows you may download and run the CGAL-3.4-Setup.exe. It is a self extracting executable that installs the CGAL source and header files, and that allows you to select and download some precompiled third party libraries.
In both cases the directory CGAL-3.4 will be created. This directory contains the following subdirectories:
directory | contents |
auxiliary | precompiled GMP, MPFR and TAUCS for Windows |
config | configuration files for install script |
cmake/modules | modules for finding and using libraries |
demo | demo programs (most of them need QT, geomview or other third-party products) |
doc_html | documentation (HTML) |
doc_pdf | documentation (PDF) |
examples | example programs |
include | header files |
scripts | some useful scripts (e.g. for creating CMakeLists.txt files) |
src | source files |
The directories include/CGAL/CORE and src/CGALCore contain a distribution of the CORE library4 version 1.7 for dealing with algebraic numbers. CORE is not part of CGAL and has its own license.
The directory include/CGAL/OpenNL contains a distribution of the Open Numerical Library which provides solvers for sparse linear systems, especially designed for the Computer Graphics community. OpenNL is not part of CGAL and has its own license.
Before building CGAL you have to choose the compiler/linker, set compiler and linker flags, specify which third-party libraries you want to use and where they can be found, which CGAL libraries you want to build. Gathering all this information is called configuration.
For CGAL-3.4, the configuration is generated with CMake, a cross-platform build system. This manual explains only those features of CMake which are needed in order to build CGAL. Please refer to the CMake documentation at http://www.cmake.org/ for further details.
When CMake has finished the configuration, it has generated a makefile or a Visual C++ solution and project file that you can use to build CGAL.
The simplest way to start the configuration is to run the graphical user interface of CMake. We recommend to use cmake-gui, which is available on all platforms since CMake release 2.6. You must pass as argument the root directory of CGAL. For example:
cd CGAL-3.4 cmake-gui . # Notice the dot to indicate the current directory.
Once cmake-gui has started up, you must press 'Configure'. A dialog will pop up and you have to choose what shall get generated. After you have made your choice and pressed 'ok', you will see the output of configuration tests in the lower window of the application. When these tests are done, you will see many red entries in the upper window. Just ignore them and press once again 'Configure'. By now CMake should have found many libraries and have initialized variables. If you still find red entries you have to provide the necessary information. This typically happens if you have installed software at non-standard locations. Providing information and pressing 'Configure' goes on until all entries are grayed. You are now ready to press 'Configure' and you can quit cmake-gui.
Alternatively, you can run the command-line tool called cmake. You pass as argument the root directory of CGAL. For example:
cd CGAL-3.4 cmake . # Notice the dot to indicate the current directory.
The very first thing CMake does is to detect the compiler to use. This detection is performed by a special CMake module called a generator. A CMake generator understands the build requirements for a particular compiler/linker and generates the necessary files for that. For example, the UNIX Makefiles generator understands the GNU toolchain (g++,gcc,ld etc) and produces makefiles which can be used to build a target by a simple call to make. Likewise, the Visual Studio 2005 generator produces solution and project files and can be manually launched in the VS IDE to build the target.
Each platform has a default generator so you only need to select one when the default is not what you want. For example, under Windows, it is possible to generate NMakefiles instead of Visual Studio project files in order to build the library with nmake. Running cmake with no parameters in a command-line prints the list of available generators supported by your platform and CMake version. If the generator you need is not listed there, you can try a newer CMake version since generators are hardcoded into CMake and more and more generators are added with each release.
Since the choice of the generator determines the type of build files to generate, in some cases you choose a particular generator as a mean to choose a specific compiler (because they use different build files). For example, the following generates solution files for use in Visual C++ 9.0:
cd CGAL-3.4 cmake -G"Visual Studio 9 2008" .
In other cases, however, the generator doesn't directly identify a specific compiler but a tool chain. For example, the UNIX Makefiles generator produces makefiles that call some auto-detected command-line compiler, like gcc. If you need the makefiles to use a different compiler you need to say so in the call to CMake, as in this example:
cd CGAL-3.4 cmake -DCMAKE_CXX_COMPILER:FILEPATH=g++-3.4 .
CMake maintains configuration parameters in so-called cmake variables, like the CMAKE_CXX_COMPILER in the example above. These variables are not environment variables but CMake variables. Some of the CMake variables represent user choices, such as WITH_examples or CMAKE_BUILD_TYPE=Release, while others indicate the details of a third-party library, such as Boost_INCLUDE_DIR or the compiler flags to use, such as CMAKE_CXX_FLAGS.
The command line tool cmake accepts CMake variables as arguments of the form -D<VAR>:<TYPE>=<VALUE>, as in the example above, but this is only useful if you already know which variables needs to be explicitly defined.
![]() | advanced |
![]() |
![]() | advanced |
![]() |
The configuration process not only determines the location of the required dependencies, it also dynamically generates a compiler_config.h file which encodes the properties of your system and a special file named CGALConfig.cmake which is used to build programs using CGAL (this file will be explained later).
CGAL is split in four libraries in order to push some auxiliary functionality out of the main library. During configuration, you can select the libraries that shall be built by setting a CMake variable of the form WITH_<library>. By default all are switched ON.
library | CMake variable | functionality | dependencies |
CGAL | none | Main library | GMP, MPFR, Boost (headers) and Boost.Thread (library) |
CGAL_Core | WITH_CGAL_Core | The CORE library for dealing with algebraic numbers.15 | GMP and MPFR |
CGAL_Qt3 | WITH_CGAL_Qt3 | CGAL::Qt_widget used by some old Qt3-based demos | Qt3 and OpenGL |
CGAL_Qt4 | WITH_CGAL_Qt4 | CGAL::GraphicsView used by the Qt4-based demos | Qt4 and OpenGL |
CGAL_ImageIO | WITH_CGAL_ImageIO | Utilities to read and write image files in various formats | OpenGL, ZLib, and VTK (optional) |
CGAL_PDB | WITH_CGAL_PDB | CGAL::PDB used to manipulate PDB files | none |
If you turn off the configuration of a library you can still configure it manually from the source directory:
cd CGAL-3.4/src/CGALQt4 cmake . # configures only the CGAL_Qt4 library
CGAL is distributed with a large collection of examples and demos. By default, these are NOT configured along with the CGAL libraries unless you set the variables WITH_examples=ON and/or WITH_demos=ON.
Nevertheless, even when configured along with CGAL, they are not automatically built along with the libraries. To do that you must explicitly build the examples or demos make targets (or IDE projects).
The CMake variable CMAKE_BUILD_TYPE can take the values Release or Debug to indicate how to build the libraries. The default depends on the platform so it is recommended that you always indicate the build type explicitly.
This is not an issue for solution/project files, as there the user selects the build type from within the IDE.
Under Windows we only support the static versions of the CGAL libraries, but on the other platforms they are by default shared libraries (.so). You can choose to produce static libraries instead by setting the CMake variable CMAKE_SHARED_LIBS=FALSE
These setting affect the variants of third-party libraries selected whenever the choice is available.
While you can choose between release/debug builds, shared/static libraries, it is not possible to generate different variants during a single configuration. To do that you need to run CMake in a different directory for each variant, each with its own selection of configuration parameters.
CMake stores the resulting makefiles/projectfiles, along with several temporary and auxiliary files such as the variables cache, in the directory where it is executed, called CMAKE_BINARY_DIR, but it takes the source files and configuration scripts from whatever directory is indicated, called CMAKE_SOURCE_DIR
The binary and source directories need not be the same, thus, you can configure multiple variants by creating a distinct directory for each configuration and by running CMake from there. This is known in CMake terminology as out-of-source configuration, as opposite to an in-source configuration as showed in the previous sections.
You can for example generate subdirectories CGAL-3.4/cmake/platforms/debug and CGAL-3.4/cmake/platforms/release for two configurations:
mkdir CGAL-3.4/cmake/platforms/debug cd CGAL-3.4/cmake/platforms/debug cmake -DCMAKE_BUILD_TYPE=Debug ../../.. mkdir CGAL-3.4/cmake/platforms/release cd CGAL-3.4/cmake/platforms/release cmake -DCMAKE_BUILD_TYPE=Release ../../..
If configuration succeeded there will be certain build files ready to build the libraries. The nature of the build files depend on the generator used during configuration, but in all cases they will contain several targets, one per library, and a default global target corresponding to all the libraries at once.
For example, in a UNIX-like environment the default generator produces makefiles and you would use the make command-line tool as follow:
cd CGAL-3.4 # build all the selected libraries at once make # build just the libraries needed for the Surface mesher demo make CGAL CGAL_ImageIO CGAL_Qt4
The libraries will all be located in a subdirectory /lib under <CMAKE_BINARY_DIR> which is CGAL-3.4 in case you run an in-source-configuration.
With generators other than UNIX Makefiles the resulting build files are solution/project files which should be launched in an IDE, such as Visual Studio or KDevelop3. They will contain the targets described above which you can manually build as any other solution/project within your IDE.
Alternatively, you can build it with the command line version of the IDE:
devenv CGAL.sln /Build Debug
The "Debug" argument is needed because CMake creates solution files with all four configurations and you need to explicitly choose one when building (the other choices are Release, RelWithDebInfo and MinSizeRel).
![]() | advanced |
![]() |
![]() | advanced |
![]() |
If you have turned on the configuration of examples and/or demos, there will be additional targets named examples and demos, plus one target for each example and each demo. None of these targets are included in the default so you need to build them explicitly after the CGAL libraries have been successfully compiled and linked The targets examples and demos include themselves all the targets for examples and demos respectively.
# build all examples at once make examples # build all demos at once make demos # build only the Straight Skeleton demo make Straight_skeleton_2_demo
![]() | advanced |
![]() |
![]() | advanced |
![]() |
On many platforms, library pieces such as headers, docs and binaries are expected to be placed in specific locations. The typical example being /usr/include or /usr/lib on UNIX-like operating systems or C:/Program Files/ on Windows. The process of placing or copying the library elements into its standard location is sometimes referred to as Installation and it is a postprocessing step after configuration and compilation.
CMake supports installation by producing a build target named install. The following example shows a typical session from configuration to installation in a UNIX-like environment:
cd CGAL-3.4 cmake . # configure make # compile make install # install
If you used a generator which produced IDE files (for Visual Studio for instance) there will be an optional INSTALL project which you can ``build'' to execute the installation step.
![]() | advanced |
![]() |
The files are copied into a directory tree relative to the installation directory determined by the CMake variable CMAKE_INSTALL_PREFIX. This variable defaults to /usr/local under UNIX-like operating systems and PROGRAMFILES under Windows. If you want to install to a different location you must override that cmake variable explicitly at configuration time (not when executing the install step).
![]() | advanced |
![]() |
The file CGALCOnfig.cmake is installed by default in $CMAKE_INSTALLED_PREFIX/lib/CGAL-3.4.
CMake can be used to configure and build user programs as well via a CMake script (CMakeLists.txt) for the program. All the examples and demos contain such CMake scripts.
During configuration of the CGAL libraries a file named CGALConfig.cmake will be generated in the binary directory. This file contains the definitions of several CMake variable which summarize the configuration of CGAL. In order to configure a user program you need to indicate the location of that config file in the CMake variable CGAL_DIR:
cd CGAL-3.4/examples/Straight_skeleton_2 cmake -DCGAL_DIR=$HOME/CGAL-3.4 . make
CGAL_DIR can also be an environment variable.
If you have installed CGAL, CGAL_DIR must afterward be set to $CMAKE_INSTALLED_PREFIX/lib/CGAL-3.4.
Normally, programs linked to CGAL must use the same flags used by the CGAL libraries to avoid runtime problems. For this reason, the very first time a program is configured, all the flags given by the CMake variables CMAKE_*_FLAGS are locked in the sense that the values recorded in CGALConfig.cmake are used to override any values given by CMake itself or yourself.
This does not apply to the additional flags that can be given via CGAL_*_FLAGS.
Such inherited values are then recorded on the current CMake cache for the program. The flags are then unlocked in the sense that at any subsequent configuration you can provide you own flags and this time they won't be overridden.
When using the interactive cmake-gui, the first press on Configure unlocks the flags so you can edit them as needed.
![]() | advanced |
![]() |
If you use the command line tool you can specify flags directly by setting the controlling variable right up front:
cd CGAL-3.4 cmake -DCMAKE_BUILD_TYPE=Release -DCMAKE_CXX_FLAGS=-g . cd CGAL-3.4/examples/Straight_skeleton_2 cmake -DCGAL_DIR=CGAL-3.4 -DCMAKE_BUILD_TYPE=Debug -DCMAKE_CXX_FLAGS=-O2 -DCGAL_DONT_OVERRIDE_CMAKE_FLAGS=TRUE .
![]() | advanced |
![]() |
Most configuration variables are not environment variables but CMake variables. They are given in the command line call to CMake via the -D option, or using the interactive cmake-gui. Unless explicitly indicated, all the variables summarized below are CMake variables.
The following boolean variables indicate which CGAL components to configure and build. Their values can be ON or OFF.
Variable | Default value |
WITH_examples | OFF |
WITH_demos | OFF |
WITH_CGAL_Core | ON |
WITH_CGAL_Qt3 | ON |
WITH_CGAL_Qt4 | ON |
WITH_CGAL_ImageIO | ON |
WITH_CGAL_PDB | ON |
The following variables specify compiler and linker flags. Each variable holds a space-separated list of command-line switches for the compiler and linker and their default values are automatically defined by CMake based on the target platform.
Have in mind that these variables specify a list of flags, not just one single flag, and if you provide your own definition for a variable you will entirely override the list of flags chosen by CMake on that particular variable.
The variables that correspond to both debug and release builds are always used in conjunction with those for the specific build type.
Program | Both Debug and Release | Release only | Debug Only |
C++ Compiler | CMAKE_CXX_FLAGS | CMAKE_CXX_FLAGS_RELEASE | CMAKE_CXX_FLAGS_DEBUG |
Linker (shared libs) | CMAKE_SHARED_LINKER_FLAGS | CMAKE_SHARED_LINKER_FLAGS_RELEASE | CMAKE_SHARED_LINKER_FLAGS_DEBUG |
Linker (static libs) | CMAKE_MODULE_LINKER_FLAGS | CMAKE_MODULE_LINKER_FLAGS_RELEASE | CMAKE_MODULE_LINKER_FLAGS_DEBUG |
Linker (programs) | CMAKE_EXE_LINKER_FLAGS | CMAKE_EXE_LINKER_FLAGS_RELEASE | CMAKE_EXE_LINKER_FLAGS_DEBUG |
The following variables can be used to add flags without overriding the ones defined by cmake.
Program | Both Debug and Release | Release only | Debug Only |
C++ Compiler | CGAL_CXX_FLAGS | CGAL_CXX_FLAGS_RELEASE | CGAL_CXX_FLAGS_DEBUG |
Linker (shared libs) | CGAL_SHARED_LINKER_FLAGS | CGAL_SHARED_LINKER_FLAGS_RELEASE | CGAL_SHARED_LINKER_FLAGS_DEBUG |
Linker (static libs) | CGAL_MODULE_LINKER_FLAGS | CGAL_MODULE_LINKER_FLAGS_RELEASE | CGAL_MODULE_LINKER_FLAGS_DEBUG |
Linker (programs) | CGAL_EXE_LINKER_FLAGS | CGAL_EXE_LINKER_FLAGS_RELEASE | CGAL_EXE_LINKER_FLAGS_DEBUG |
Variable | Description | Type | Default value |
CMAKE_BUILD_TYPE | Indicates type of build. Possible values are 'Debug' or 'Release' | CMake | Release |
CMAKE_CXX_COMPILER | Full-path to the executable corresponding to the C++ compiler to use. | CMake | platform-dependent |
CXX | Idem | Environment | Idem |
Variable | Description | Type | Default value |
CGAL_DIR | Full-path to the binary directory where CGAL was configured | Either CMake or Environment | none |
The following variables provide information about the availability and location of the 3rd party libraries used by CGAL. CMake automatically searches for dependencies so you only need to specify these variables if they are given a value ending in NOTFOUND (which indicates that CMake was unable to locate something)
Since 3rd-party libraries are system wide many of the CMake variables listed below can alternatively be given as similarly-named environment variables instead. Keep in mind that you must provide one or the other but never both.
In most cases, if boost is not automatically found, setting the BOOST_ROOT variable is enough. If it is not, you can specify the headers and libraries directories individually. You can also provide the full pathname to a specific compiled library if it cannot be found in the libs directory or its name is non-standard.
Variable | Description | Type |
BOOST_ROOT16 | Root directory of your boost installation | Either CMake or Environment |
Boost_INCLUDE_DIR | Directory containing the boost/version.hpp file | CMake |
BOOST_INCLUDEDIR | Idem | Environment |
Boost_LIBRARY_DIRS | Directory containing the compiled boost libraries | CMake |
BOOST_LIBRARYDIR | Idem | Environment |
Boost_(xyz)_LIBRARY_RELEASE | Full pathname to a release build of the compiled 'xyz' boost library | CMake |
Boost_(xyz)_LIBRARY_DEBUG | Full pathname to a debug build of the compiled 'xyz' boost library | CMake |
Under Windows, auto-linking is used, so only the directory containing the libs is needed and you would specify GMP|MPFR_LIBRARY_DIR rather than GMP|MPFR_LIBRARIES. On the other hand, under Linux the actual library filename is needed thus you would specify GMP|MPFR_LIBRARIES. In no case you need to specify both.
CGAL uses both gmp and mpfr so both need to be supported. If either of them is unavailable the usage of gmp-mpfr will be disabled.
Variable | Description | Type |
WITH_GMP | Indicates whether to search and use gmp/mpfr or not | CMake |
GMP_INCLUDE_DIR | Directory containing the gmp.h file | CMake |
GMP_INC_DIR | Idem | Environment |
GMP_LIBRARIES_DIR | Directory containing the compiled gmp library | CMake |
GMP_LIB_DIR | Idem | Environment |
GMP_LIBRARIES | Full pathname of the compiled gmp library | CMake |
MPFR_INCLUDE_DIR | Directory containing the mpfr.h file | CMake |
MPFR_INC_DIR | Idem | Environment |
MPFR_LIBRARIES_DIR | Directory containing the compiled mpfr library | CMake |
MPFR_LIB_DIR | Idem | Environment |
MPFR_LIBRARIES | Full pathname of the compiled mpfr library | CMake |
Under Linux, the GMPXX may also searched for and you might specify the following variables:
Variable | Description | Type |
GMPXX_INCLUDE_DIR | Directory containing the gmpxx.h file | CMake |
GMPXX_LIBRARIES | Full pathname of the compiled gmpxx library | CMake |
When the LEDA libraries are not automatically found, yet they are installed in the system with base names 'leda' and 'ledaD' (for the release and debug versions resp.), it might be sufficient to just indicate the library directory via the LEDA_LIBRARY_DIRS variable. If that doesn't work because the names are different, you can provide the full pathnames of each variant via LEDA_LIBRARY_RELEASE and LEDA_LIBRARY_DEBUG.
The variables specifying definitions and flags can be left undefined if they are not needed by LEDA.
Variable | Description | Type |
WITH_LEDA | Indicates whether to search and use LEDA or not | CMake |
LEDA_INCLUDE_DIR | Directory containing the file LEDA/system/basic.h | Either CMake or Environment |
LEDA_LIBRARY_DIRS | Directory containing the compiled LEDA libraries | Either CMake or Environment |
LEDA_LIBRARY_RELEASE | Full pathname to a release build of the LEDA library | Either CMake or Environment |
LEDA_LIBRARY_DEBUG | Full pathname to a debug build of the LEDA library | Either CMake or Environment |
LEDA_DEFINITIONS | Preprocessor definitions | Either CMake or Environment |
LEDA_CXX_FLAGS | Compiler flags | Either CMake or Environment |
LEDA_LINKER_FLAGS | Linker flags | Either CMake or Environment |
In most cases, if Qt3 is not automatically found, setting the QTDIR environment variable is enough. If it is not, you can specify the directory containing the header files and the full pathnames of the Qt3 libraries.
Variable | Description | Type |
QTDIR | Root directory of the Qt3 library | Environment |
QT3_INCLUDE_DIR | Directory containing the qt.h file | CMake |
QT3_QT_LIBRARY | Full pathname to the qt library of Qt3 | CMake |
QT3_QTMAIN_LIBRARY | Full pathname to the qtmain library of Qt3 | CMake |
QT3_QASSISTANTCLIENT_LIBRARY | Full pathname to the qassistantclient library of Qt3 | CMake |
QT3_MOC_LIBRARY | Full pathname to the moc executable of Qt3 | CMake |
QT3_UIC_LIBRARY | Full pathname to the uic executable of Qt3 | CMake |
The CMake scripts that search for Qt4 can use the introspection feature of the tool qmake present in Qt4 distributions. If Qt4 is not automatically found, it is sufficient to set the PATH environment variable so that Qt4 qmake tool is in the path, and before Qt3 qmake is that one exists. One can alternatively set the CMake variable QT_QMAKE_EXECUTABLE. The following variables should be then filled automatically by CMake.
Variable | Description | Type |
QT_INCLUDE_DIR | Directory containing the QtCore/qglobal.h file | CMake |
QT_LIBRARY_DIR | Directory containing the compiled Qt4 libraries | CMake |
QT_(xyz)_LIBRARY | Full pathname to the compiled 'xyz' Qt4 library17 | CMake |
QT_QMAKE_EXECUTABLE | Full pathname to the qmake executable of Qt4 | CMake |
QT3_MOC_LIBRARY | Full pathname to the moc executable of Qt4 | CMake |
QT3_UIC_LIBRARY | Full pathname to the uic executable of Qt4 | CMake |
Some demos require the GLViewer library.
In most cases, if QGLViewer is not automatically found, setting the QGLVIEWERROOT environment variable is enough. If it is not, you can specify the directory containing the header files and the full pathnames of the release and debug libraries
Variable | Description | Type |
QGLVIEWERROOT | Root directory of the QGViewer library | Environment |
QGLVIEWER_INCLUDE_DIR | Directory containing the QGLViewer/qglviewer.h file | CMake |
QGLVIEWER_LIBRARY_RELEASE | Full pathname to a release build of the QGLViewer library | CMake |
QGLVIEWER_LIBRARY_DEBUG | Full pathname to a debug build of the QGLViewer library | CMake |
Some demos require the TAUCS and METIS libraries. Both must be found otherwise the TAUCS support will not be activated.
Under Windows, auto-linking is used, so only the directory containing the libs is needed and you would specify TAUCS_LIBRARY_DIR rather than TAUCS_LIBRARIES. On the other hand, under Linux the actual library filename is needed thus you would specify TAUCS_LIBRARIES. In no case you need to specify both.
CGAL uses both TAUCS and METIS so both need to be supported. If either of them is unavailable the usage of TAUCS-METIS will be disabled.
Variable | Description | Type |
TAUCS_INCLUDE_DIR | Directory containing the taucs.h file | CMake |
TAUCS_INC_DIR | Idem | Environment |
TAUCS_LIBRARIES_DIR | Directory containing the compiled taucs library | CMake |
TAUCS_LIB_DIR | Idem | Environment |
TAUCS_LIBRARY | Full pathname of the compiled taucs library | CMake |
METIS_LIBRARY | Full pathname of the compiled metis library | CMake |
A few demos require some BLAS and LAPACK functions. There are many vendor specific libraries implementing that and CMake searches for most of them.
If they are not found, you can indicate the directory containing the libraries, or provide a semi-colon separated list of pathnames to the libraries which collectively implement the functionality.
Many of the libraries implementing BLAS and LAPACK require the F2C library for Fortran-to-C convertion. If this is needed and not found you might specify the fullpath of the library in the F2C_LIBRARIES variable. You do not need to provide this if the BLAS|LAPACK libraries do not need f2c.
Variable | Description | Type |
BLAS_INCLUDE_DIR | Directory containing blas header files | CMake |
BLAS_LIBRARIES_DIR | Directory containing the compiled libraries implementing BLAS | Environment |
BLAS_LIB_DIR | Idem | Environment |
BLAS_LIBRARIES | Semi-colon separated list of library pathnames implementing the BLAS functions | CMake |
BLAS_LINKER_FLAGS | Linker flags | CMake |
BLAS_DEFINITIONS | Preprocessor definitions | CMake |
LAPACK_INCLUDE_DIR | Directory containing blas header files | CMake |
LAPACK_LIBRARIES_DIR | Directory containing the compiled libraries implementing LAPACK | Environment |
LAPACK_LIB_DIR | Idem | Environment |
LAPACK_LIBRARIES | Semi-colon separated list of library pathnames implementing the LAPACK functions | CMake |
LAPACK_LINKER_FLAGS | Linker flags | CMake |
LAPACK_DEFINITIONS | Preprocessor definitions | CMake |
F2C_LIBRARIES | Full pathname to the f2c library | CMake |
Here is an example output on a Windows machine with VC8 installed, using CMake 2.6, and the following command-line call to cmake:
cmake -DWITH_examples=false -DWITH_demos=false -DCMAKE_BUILD_TYPE=Release ../../..
-- Check for working C compiler: cl -- Check for working C compiler: cl -- works -- Detecting C compiler ABI info -- Detecting C compiler ABI info - done -- Check for working CXX compiler: cl -- Check for working CXX compiler: cl -- works -- Detecting CXX compiler ABI info -- Detecting CXX compiler ABI info - done -- CGAL_REFERENCE_CACHE_DIR= -- Building static libraries -- Targetting Visual Studio 8 2005 -- Target build environment supports auto-linking -- Using VC80 compiler. -- Build type: Release -- Generator uses intermediate configuration directory: $(OutDir) -- CMake version: 2.6.1 -- System: Windows -- CGAL_MAJOR_VERSION=3 -- CGAL_MINOR_VERSION=4 -- CGAL_BUILD_VERSION=442 -- CGAL_SONAME_VERSION=3 -- CGAL_SOVERSION =3.0.0 -- Boost version: 1.35.0 -- Found the following Boost libraries: -- thread -- Boost include: C:/Program Files/boost/boost_1_35_0 -- Boost libraries: -- Boost definitions: -- USING BOOST_VERSION = '1.35.0' -- Could NOT find GMP -- Could NOT find MPFR -- Performing Test CGAL_CFG_DENORMALS_COMPILE_BUG - Success -- Performing Test CGAL_CFG_IEEE_754_BUG - Success -- Performing Test CGAL_CFG_ISTREAM_INT_BUG - Success -- Performing Test CGAL_CFG_LONGNAME_BUG - Failed -- Performing Test CGAL_CFG_MATCHING_BUG_5 - Success -- Performing Test CGAL_CFG_MATCHING_BUG_6 - Failed -- Performing Test CGAL_CFG_NESTED_CLASS_FRIEND_DECLARATION_BUG - Failed -- Performing Test CGAL_CFG_NET2003_MATCHING_BUG - Failed -- Performing Test CGAL_CFG_NO_CPP0X_ARRAY - Failed -- Performing Test CGAL_CFG_NO_CPP0X_DECLTYPE - Failed -- Performing Test CGAL_CFG_NO_CPP0X_DEFAULT_TEMPLATE_ARGUMENTS_FOR_FUNCTION_TEMPLATES - Failed -- Performing Test CGAL_CFG_NO_CPP0X_DELEGATING_CONSTRUCTORS - Failed -- Performing Test CGAL_CFG_NO_CPP0X_ISFINITE - Failed -- Performing Test CGAL_CFG_NO_CPP0X_LONG_LONG - Success -- Performing Test CGAL_CFG_NO_CPP0X_RVALUE_REFERENCE - Failed -- Performing Test CGAL_CFG_NO_CPP0X_VARIADIC_TEMPLATES - Failed -- Performing Test CGAL_CFG_NO_LIMITS - Success -- Performing Test CGAL_CFG_NO_NEXTAFTER - Failed -- Performing Test CGAL_CFG_NO_STATEMENT_EXPRESSIONS - Failed -- Performing Test CGAL_CFG_NO_STL - Success -- Performing Test CGAL_CFG_NO_TMPL_IN_TMPL_PARAM - Success -- Performing Test CGAL_CFG_NO_TR1_ARRAY - Failed -- Performing Test CGAL_CFG_NUMERIC_LIMITS_BUG - Success -- Performing Test CGAL_CFG_OUTOFLINE_MEMBER_DEFINITION_BUG - Success -- Performing Test CGAL_CFG_TYPENAME_BEFORE_DEFAULT_ARGUMENT_BUG - Failed -- Performing Test CGAL_CFG_USING_BASE_MEMBER_BUG_2 - Success -- CMAKE_INSTALL_PREFIX=C:/Program Files/CGAL -- USING CUSTOM_CXXFLAGS = ' -D_CRT_SECURE_NO_DEPRECATE -D_SCL_SECURE_NO_DEPRECATE -D_CRT_SECURE_NO_WARNINGS -D_SCL_SECURE_NO_WARNINGS -D_SECURE_SCL=0' -- USING CXXFLAGS = ' /DWIN32 /D_WINDOWS /W3 /Zm1000 /EHsc /GR /MD /O2 /Ob2 /D NDEBUG' -- USING CUSTOM_LDFLAGS = ' ' -- USING LDFLAGS = ' ' -- USING CUSTOM_EXEFLAGS = ' ' -- USING EXEFLAGS = ' /MANIFEST /STACK:10000000 /machine:I386 /INCREMENTAL:NO' -- Configuring CGALCore. Set WITH_CGALCore to FALSE to unselect it. -- CGAL-core++ needs GMP and MPFR, cannot be configured. -- Configuring CGALimageIO. Set WITH_CGALimageIO to FALSE to unselect it. -- Could NOT find ZLIB -- CGAL-ImageIO needs ZLib and OpenGL, cannot be configured. -- Configuring CGALPDB. Set WITH_CGALPDB to FALSE to unselect it. -- Configuring CGALQt. Set WITH_CGALQt to FALSE to unselect it. -- CGAL-Qt3 needs Qt3, cannot be configured. -- Configuring CGALQt4. Set WITH_CGALQt4 to FALSE to unselect it. -- Looking for Q_WS_X11 -- Looking for Q_WS_X11 - not found. -- Looking for Q_WS_WIN -- Looking for Q_WS_WIN - found -- Looking for Q_WS_QWS -- Looking for Q_WS_QWS - not found. -- Looking for Q_WS_MAC -- Looking for Q_WS_MAC - not found. -- OpenGL include: -- OpenGL libraries: glu32;opengl32 -- OpenGL definitions: -- Qt4 include: C:/Work/Downloaded/Libraries/qt-win-opensource-src-4.4.1/include -- Qt4 libraries: optimized;C:/Work/Downloaded/Libraries/qt-win-opensource-src-4.4.1/lib/qtmain.lib;debug;C:/Work/Downloaded/Libraries/qt-win-opensource-src-4.4.1/lib/qtmaind.lib;optimized;C:/Work/Downloaded/Libraries/qt-win-opensource-src-4.4.1/lib/QtOpenGL4.lib;debug;C:/Work/Downloaded/Libraries/qt-win-opensource-src-4.4.1/lib/QtOpenGLd4.lib;opengl32.lib glu32.lib gdi32.lib user32.lib;optimized;C:/Work/Downloaded/Libraries/qt-win-opensource-src-4.4.1/lib/QtGui4.lib;debug;C:/Work/Downloaded/Libraries/qt-win-opensource-src-4.4.1/lib/QtGuid4.lib;imm32;winmm;optimized;C:/Work/Downloaded/Libraries/qt-win-opensource-src-4.4.1/lib/QtCore4.lib;debug;C:/Work/Downloaded/Libraries/qt-win-opensource-src-4.4.1/lib/QtCored4.lib;ws2_32 -- Qt4 definitions: -DQT_DLL -- moc executable: C:/Work/Downloaded/Libraries/qt-win-opensource-src-4.4.1/bin/moc.exe -- uic executable: C:/Work/Downloaded/Libraries/qt-win-opensource-src-4.4.1/bin/uic.exe -- Configuring done -- Generating done -- Build files have been written to: C:/Work/Active/GeometryFactory/CGAL/Autotest/CGAL-3.4-I-442/cmake/platforms/a
In CGAL, a number of compiler flags is defined. All of them start with the prefix CGAL_CFG. These flags are used to work around compiler bugs and limitations. For example, the flag CGAL_CFG_NO_LONG_LONG denotes that the compiler does not know the type long long.
For each compiler a file <CGAL/compiler_config.h> is defined, with the correct settings of all flags. This file is generated automatically by CMake, and it is located in the include directory of where you run CMake. For an in-source configuration this means CGAL-3.4/include.
The test programs used to generate the compiler_config.h file can be found in config/testfiles. Both compiler_config.h and the test programs contain a short description of the problem. In case of trouble with one of the CGAL_CFG flags, it is a good idea to take a look at it.
The file CGAL/compiler_config.h is included from <CGAL/config.h>. which is included by all CGAL header files.
Some compilers do still not provide a complete standard library. In particular they fail to provide the C++ wrappers for files from the standard C library, like cstddef for stddef.h. The CGAL install scripts checks for all standard header files and generates a simple wrapper file in the CGAL include directory for those that are missing. These wrapper files include the corresponding C header files and add all symbols required by the C++ standard into namespace std. You can turn off the additions to namespace std by defining the macro CGAL_NO_STDC_NAMESPACE.
By default CMake generates makefiles for Release mode, with optimization flags switched on, and vcproj files for Release and Debug mode.
The Bourne-shell script cgal_create_cmake_script is contained in the CGAL-3.4/scripts directory. It can be used to create CmakeLists.txt files for compiling CGAL applications. Executing cgal_create_cmake_script in an application directory creates a CMakeLists.txt containing rules for every *.cpp file there.
10 | http://gcc.gnu.org/ |
11 | http://msdn.microsoft.com/visualc/ |
12 | http://developer.intel.com/software/products/compilers/ |
4 | http://www.cs.nyu.edu/exact/core\_pages/ |
15 | CGAL-core++ is not part of CGAL, it is a custom version the CORE library distributed by CGAL for the user convenience and it has it's own license. |
16 | The environment variable can be spelled either BOOST_ROOT or BOOSTROOT |
17 | If both release and debug versions are available, this variable contains a list of the following form: 'optimized;<fullpath-to-release-lib>;debug;<fullpath-to-debug-lib>', where the 'optimized' and 'debug' tags should appear verbatim. |