11 Building CGAL
The results of a successful configuration are build files that control the build step. The nature of the build files depends on the generator used during configuration, but in all cases they contain several targets, one per library, and a default global target corresponding to all the libraries.
For example, in a Unix-like environment the default generator produces makefiles. You can use the makecommand-line tool for the succeeding build step as follows:
cd CGAL-4.4# build all the selected libraries at oncemakeThe resulting libraries are placed in the subdirectory lib under <CMAKE_BINARY_DIR> (which is CGAL-4.4 in case you run an in-source-configuration).
With generators other than UNIX Makefiles the resulting build files are solution and 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 with any other solution/project within your Ide.
Alternatively, you can build it with the command line version of the Visual Studio Ide:
代码语言：javascript复制devenv CGAL.sln /Build DebugThe "Debug" argument is needed because CMake creates solution files for all four configurations, and you need to explicitly choose one when building (the other choices are Release, RelWithDebInfo and MinSizeRel).
Advanced
The build files produced by CMake are autoconfigured. That is, if you change any of the dependencies, the build step automatically goes all the way back to the configuration step. This way, once the target has been configured the very first time by invoking cmake, you don't necessarily need to invoke cmake again. Rebuilding will call itself cmake and re-generate the build file whenever needed. Keep this in mind if you configure CGAL for the Visual Studio IDE since a build could then change the solution/project file in-place and VS will prompt you to reload it.
If you have turned on the configuration of examples (-DWITH_examples=ON) and/or demos (-DWITH_demos=ON), there will be additional targets named examples and demos, plus one target for each example and each demo in the build files. None of these targets are included by default, so you need to build them explicitly after the CGAL libraries have been successfully built. 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_demoAdvanced
When using UNIX Makefiles you can find out the exact name of the example or demo target of a particular package by typing make help | grep <package>.
12 Installing CGAL
On many platforms, library pieces such as headers, docs and binaries are expected to be placed in specific locations. A typical example being /usr/include and /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 the build step.
CMake carries out the installation by producing a build target named install. The following example shows a typical session from configuration to installation in a Unix-like environment:
代码语言：javascript复制cd CGAL-4.4
cmake . # configure
make # compile
make install # installIf you use a generator that produces IDE files (for Visual Studio for instance) there will be an optional INSTALL project, which you will be able to "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 C:Program Files under Windows. If you want to install to a different location, you must override that CMake variable explicitly at the configuration time and not when executing the install step.
The file CGALConfig.cmake is installed by default in $CMAKE_INSTALLED_PREFIX/lib/CGAL-4.4.
13 Example Configuration
Below is an example output on a linux machine with g 4.4 installed, using CMake 2.8.5, and the following command-line call to cmake:
cmake -DWITH_examples=OFF -DWITH_demos=OFF -DCMAKE_BUILD_TYPE=Release
/path/to/unpacked/CGAL-tarball/
-- The CXX compiler identification is GNU
-- The C compiler identification is GNU
-- Check for working CXX compiler: /usr/bin/g -4.4
-- Check for working CXX compiler: /usr/bin/g -4.4 -- works
-- Detecting CXX compiler ABI info
-- Detecting CXX compiler ABI info - done
-- Check for working C compiler: /usr/bin/gcc-4.4
-- Check for working C compiler: /usr/bin/gcc-4.4 -- works
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - done
== Setting paths ==
== Build CGAL from release: CGAL-4.1 ==
-- Packagenames: CGAL-4.1
== Setting paths (DONE) ==
== Generate version files ==
-- CGAL_MAJOR_VERSION=4
-- CGAL_MINOR_VERSION=1
-- CGAL_BUGFIX_VERSION=0
-- CGAL_SONAME_VERSION=10
-- CGAL_SOVERSION =10.0.0
-- CGAL_REFERENCE_CACHE_DIR=
-- Building shared libraries
-- Targetting Unix Makefiles
-- Using /usr/bin/g -4.4 compiler.
-- USING CMake version: 2.8.5
-- System: Linux
-- USING GCC_VERSION = '4.4.5'
-- Using gcc version 4 or later. Adding -frounding-math
== Generate version files (DONE) ==
== Detect external libraries ==
-- Build type: Release
-- USING CXXFLAGS = ' -frounding-math -O3 -DNDEBUG'
-- USING LDFLAGS = ' '
-- External libraries supported: GMP;GMPXX;MPFR;zlib;OpenGL;LEDA;MPFI;RS;RS3;OpenNL;TAUCS;EIGEN3;BLAS;LAPACK;QGLViewer;ESBTL;NTL
-- Preconfiguring library: GMP ...
-- GMP has been preconfigured:
-- CGAL_UseGMP-file:
-- GMP include: /usr/include/
-- GMP libraries: /usr/lib/libgmp.so
-- GMP definitions:
-- USING GMP_VERSION = '4.3.2'
-- Preconfiguring library: GMPXX ...
-- GMPXX has been preconfigured:
-- CGAL_UseGMPXX-file:
-- GMPXX include: /usr/include
-- GMPXX libraries: /usr/lib/libgmpxx.so
-- GMPXX definitions:
-- Preconfiguring library: MPFR ...
-- MPFR has been preconfigured:
-- CGAL_UseMPFR-file:
-- MPFR include: /usr/include/
-- MPFR libraries: /usr/lib/libmpfr.so
-- MPFR definitions:
-- USING MPFR_VERSION = '3.0.0'
-- Boost version: 1.39.0
-- Found the following Boost libraries:
-- thread
-- Boost include: /usr/include/boost_1_39_0/include/boost-1_39
-- Boost libraries: /usr/lib/libboost_thread-mt.so;pthread
-- Boost definitions:
-- USING BOOST_VERSION = '1.39.0'
== Detect external libraries (DONE) ==
== Write compiler_config.h ==
-- Performing Test CGAL_CFG_ARRAY_MEMBER_INITIALIZATION_BUG - Success
-- Performing Test CGAL_CFG_DENORMALS_COMPILE_BUG - Success
-- Performing Test CGAL_CFG_FPU_ROUNDING_MODE_UNWINDING_VC_BUG - Success
-- Performing Test CGAL_CFG_IEEE_754_BUG - Success
-- Performing Test CGAL_CFG_ISTREAM_INT_BUG - Success
-- Performing Test CGAL_CFG_LONGNAME_BUG - Success
-- Performing Test CGAL_CFG_MATCHING_BUG_5 - Success
-- Performing Test CGAL_CFG_MATCHING_BUG_6 - Success
-- Performing Test CGAL_CFG_NESTED_CLASS_FRIEND_DECLARATION_BUG - Success
-- Performing Test CGAL_CFG_NO_CPP0X_ARRAY - Failed
-- Performing Test CGAL_CFG_NO_CPP0X_AUTO - Failed
-- Performing Test CGAL_CFG_NO_CPP0X_COPY_N - 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_DELETED_AND_DEFAULT_FUNCTIONS - Success
-- Performing Test CGAL_CFG_NO_CPP0X_INITIALIZER_LISTS - Failed
-- Performing Test CGAL_CFG_NO_CPP0X_ISFINITE - Success
-- Performing Test CGAL_CFG_NO_CPP0X_LAMBDAS - Failed
-- Performing Test CGAL_CFG_NO_CPP0X_LONG_LONG - Success
-- Performing Test CGAL_CFG_NO_CPP0X_NEXT_PREV - Failed
-- Performing Test CGAL_CFG_NO_CPP0X_RVALUE_REFERENCE - Failed
-- Performing Test CGAL_CFG_NO_CPP0X_STATIC_ASSERT - Failed
-- Performing Test CGAL_CFG_NO_CPP0X_TUPLE - Failed
-- Performing Test CGAL_CFG_NO_CPP0X_VARIADIC_TEMPLATES - Failed
-- Performing Test CGAL_CFG_NO_LIMITS - Success
-- Performing Test CGAL_CFG_NO_LOGICAL_OPERATORS_ALTERNATIVES - Success
-- Performing Test CGAL_CFG_NO_MESSAGE_PRAGMA_BUG - Success
-- Performing Test CGAL_CFG_NO_NEXTAFTER - Success
-- Performing Test CGAL_CFG_NO_STATEMENT_EXPRESSIONS - Success
-- Performing Test CGAL_CFG_NO_STL - Success
-- Performing Test CGAL_CFG_NO_TR1_ARRAY - Success
-- Performing Test CGAL_CFG_NO_TR1_TUPLE - Success
-- Performing Test CGAL_CFG_NO_WARNING_CPP_DIRECTIVE_BUG - Success
-- Performing Test CGAL_CFG_NUMERIC_LIMITS_BUG - Success
-- Performing Test CGAL_CFG_OUTOFLINE_MEMBER_DEFINITION_BUG - Success
-- Performing Test CGAL_CFG_TEMPLATE_IN_DEFAULT_PARAMETER_BUG - Success
-- Performing Test CGAL_CFG_TYPENAME_BEFORE_DEFAULT_ARGUMENT_BUG - Success
-- Performing Test CGAL_CFG_USING_BASE_MEMBER_BUG_2 - Success
== Write compiler_config.h (DONE) ==
== Generating build files ==
-- Configure libCGAL
-- GMP include: /usr/include/
-- GMP definitions:
-- GMP libraries: /usr/lib/libgmp.so
-- Configured GMP in standard way
-- MPFR include: /usr/include/
-- MPFR definitions:
-- MPFR libraries: /usr/lib/libmpfr.so
-- Configured MPFR in standard way
-- libCGAL is configured
-- Sources for CGAL component library 'Core' detected
-- Configure libCGALCore
-- GMP include: /usr/include/
-- GMP definitions:
-- GMP libraries: /usr/lib/libgmp.so
-- Configured GMP in standard way
-- MPFR include: /usr/include/
-- MPFR definitions:
-- MPFR libraries: /usr/lib/libmpfr.so
-- Configured MPFR in standard way
-- libCGALCore is configured
-- Sources for CGAL component library 'Qt3' detected
-- Sources for CGAL component library 'Qt4' detected
-- Configure libCGALQt4
-- Looking for Q_WS_X11
-- Looking for Q_WS_X11 - found
-- Looking for Q_WS_WIN
-- Looking for Q_WS_WIN - not 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.
-- Looking for XOpenDisplay in /usr/lib/libX11.so;/usr/lib/libXext.so
-- Looking for XOpenDisplay in /usr/lib/libX11.so;/usr/lib/libXext.so - found
-- Looking for gethostbyname
-- Looking for gethostbyname - found
-- Looking for connect
-- Looking for connect - found
-- Looking for remove
-- Looking for remove - found
-- Looking for shmat
-- Looking for shmat - found
-- Looking for IceConnectionNumber in ICE
-- Looking for IceConnectionNumber in ICE - found
-- Found X11: /usr/lib/libX11.so
-- USING QT4_VERSION = '4.6.3'
-- OpenGL include: /usr/include
-- OpenGL libraries: /usr/lib/libGLU.so;/usr/lib/libGL.so;/usr/lib/libSM.so;/usr/lib/libICE.so;/usr/lib/libX11.so;/usr/lib/libXext.so
-- OpenGL definitions:
-- Qt4 include: /usr/include/qt4
-- Qt4 libraries: /usr/lib/libQtOpenGL.so;/usr/lib/libQtGui.so;/usr/lib/libQtCore.so
-- Qt4 definitions:
-- moc executable: /usr/bin/moc-qt4
-- uic executable: /usr/bin/uic-qt4
-- GMP include: /usr/include/
-- GMP definitions:
-- GMP libraries: /usr/lib/libgmp.so
-- Configured GMP in standard way
-- MPFR include: /usr/include/
-- MPFR definitions:
-- MPFR libraries: /usr/lib/libmpfr.so
-- Configured MPFR in standard way
-- libCGALQt4 is configured
-- Sources for CGAL component library 'ImageIO' detected
-- Configure libCGALImageIO
-- Found OpenGL: /usr/lib/libGL.so
-- Found ZLIB: /usr/lib/libz.so (found version "1.2.3.4")
-- OpenGL include: /usr/include
-- OpenGL libraries: /usr/lib/libGLU.so;/usr/lib/libGL.so;/usr/lib/libSM.so;/usr/lib/libICE.so;/usr/lib/libX11.so;/usr/lib/libXext.so
-- USING ZLIB_VERSION = '1.2.3.4'
-- libCGALImageIO is configured
-- Sources for CGAL component libraries 'CGAL;Core;ImageIO;Qt3;Qt4' detected
== Generating build files (DONE) ==
-- Configuring done
-- Generating done
-- Build files have been written to: /home/user/CGAL/4.1/
14 Multiple Variants of Makefiles (out-of-source build)
While you can choose between release or debug builds, and shared or static libraries, it is not possible to generate different variants during a single configuration. You need to run CMake in a different directory for each variant you are interested in, each with its own selection of configuration parameters.
CMake stores the resulting makefiles and project files, 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 CMAKE_SOURCE_DIR.
The binary and source directories do not need to 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-4.4/cmake/platforms/debug and CGAL-4.4/cmake/platforms/release for two configurations, respectively:
mkdir CGAL-4.4/cmake/platforms/debug
cd CGAL-4.4/cmake/platforms/debug
cmake -DCMAKE_BUILD_TYPE=Debug ../../..
mkdir CGAL-4.4/cmake/platforms/release
cd CGAL-4.4/cmake/platforms/release
cmake -DCMAKE_BUILD_TYPE=Release ../../..15 Configuring and Building Programs Using CGAL
Ideally, configuring and compiling a demo/example/program amounts to
代码语言：javascript复制cd CGAL-4.4/examples/Straight_skeleton_2
cmake -DCGAL_DIR=$HOME/CGAL-4.4 .
makeIn this ideal world, as for all shipped examples and demos of CGAL, the required CMakeLists.txt is already provided.
CMake can also be used to configure and build user programs via such CMake-scripts. In this less ideal world, one has to provide the CMakeLists.txt script either manually, or with the help of a shell-script that is introduced below.
For a user program executable.cpp, the ideal world looks like this:
cd /path/to/program
cgal_create_CMakeLists -s executable
cmake -DCGAL_DIR=$HOME/CGAL-4.4 .
makeIn both examples we specify the CGAL_DIR: During configuration of the CGAL libraries a file named CGALConfig.cmake is generated in CGAL's root directory (in contrast to CGAL's source directory that has been used for installation). This file contains the definitions of several CMake variable that summarize the configuration of CGAL. In order to configure a program, you need to indicate the location of that config file in the CMake variable CGAL_DIR (as indicated in the example above). CGAL_DIR can also be an environment variable. Setting CGAL_DIR makes particular sense if having multiple out-of-source builds of CGAL as in Section Multiple Variants of Makefiles (out-of-source build).
If you have installed CGAL, CGAL_DIR must afterwards be set to $CMAKE_INSTALLED_PREFIX/lib/CGAL. Note that CGAL is recommended to be installed in release mode when using it to build programs.
15.1 Creating a CMake Script for a Program Using CGAL
For compiling a non-shipped program, it is recommended, to also rely on a CMake-supported configuration using a CMakeLists.txt used for configuration.
Use the following Bourne-shell script for programs that are relatively simple to configure:
15.2 cgal_create_CMakeLists
The Bourne-shell script cgal_create_CMakeLists.txt resides in the CGAL-4.4/scripts directory. It can be used to create CMakeLists.txt files for compiling CGAL applications. Executing cgal_create_CMakeLists.txtin an application directory creates a CMakeLists.txt containing rules to build the contained application(s). Three command line options determine details of the configuration.
-s source
If this parameter is given the script will create a single executable for 'source' linked with compilations of all other source files (*.cpp). This behaviour is usually needed for (graphical) demos.
If the parameter is not given, the script creates one executable for each given source file.
-c com1:com2:...
Lists components ("com1", "com2") of CGAL to which the executable(s) should be linked. Valid components are CGAL's libraries (i.e. "Core", "ImageIO", "Qt3" and "Qt4"; note that it only make sense to either pick "Qt3" or "Qt4") and all preconfigured 3rd party software, such as "MPFI", "RS3"). An example is -c Core:GMP:RS3:MPFI
-b boost1:boost2:...
Lists components ("boost1", "boost2") of Boost to which the executable(s) should be linked. Valid options are, for instance, "filesystem" or "program_options".
This options should suffice to create CMakeLists.txt script for most directories containing programs. However, in some special cases, it might still be required to create the script manually, for instance, if some source files/executables need a different linking than other source files.
15.3 cgal_create_cmake_script
Such a shell-script simply creates a CMake script. Processing it with CMake, searches for CGAL using find_package. If found, the variable CGAL_USE_FILE is set to a compilation environment CMake file. Including this file within a CMake script sets up include paths and libraries to link with CGAL and essential third party libraries. Beyond, find_package can demand for COMPONENTS of CGAL, that is, all CGAL libraries libCGAL_Core (Core), libCGAL_ImageIO (ImageIO) , libCGAL_Qt3 (Qt3) and libCGAL_Qt4 (Qt4) or optional 3rd party software such as MPFI, RS3. A user is free to create the CMakeLists.txt without calling the script (manual creation).
15.4 Custom Flags in the Programs Using CGAL
Normally, programs linked with CGAL must be compiled with the same flags used by the compilation of CGAL libraries. 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 in the current CMake cache for the program. The flags are then unlocked in the sense that at any subsequent configuration you can provide your own flags and this time they will not be overridden.
When using the interactive cmake-gui the first press on Configure unlocks the flags, so that you can edit them as needed.
Advanced
The locking of flags is controlled by the variable CGAL_DONT_OVERRIDE_CMAKE_FLAGS which starts out FALSE and is toggled right after the flags have been loaded from CGALConfig.cmake.
If you use the command line tool you can specify flags directly by setting the controlling variable right up front:
代码语言：javascript复制cd CGAL-4.4
cmake -DCMAKE_BUILD_TYPE=Release -DCMAKE_CXX_FLAGS=-g .
cd CGAL-4.4/examples/Straight_skeleton_2
cmake -DCGAL_DIR=CGAL-4.4 -DCMAKE_BUILD_TYPE=Debug -DCMAKE_CXX_FLAGS=-O2 -DCGAL_DONT_OVERRIDE_CMAKE_FLAGS=TRUE . 16 Summary of CGAL's Configuration Variables
Most configuration variables are not environment variables but CMake variables. They are given in the command line to CMake via the -D option, or passed from the interactive interface of cmake-gui. Unless indicated differently, all the variables summarized below are CMake variables.
16.1 Component Selection
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 |
16.2 Compiler and Linker Flags
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. If you provide your own definition for a variable, you will entirely override the list of flags chosen by CMake for 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 |
16.3 Additional Compiler and Linker Flags
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 |
16.4 Miscellaneous Variables
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 |
16.5 Variables Used Only When Building Programs (Such as Demos or Examples)
Variable | Description | Type | Default Value |
|---|---|---|---|
CGAL_DIR | Full-path to the binary directory where CGAL was configured | Either CMake or Environment | none |
16.6 Variables Providing Information About 3rd-Party Libraries
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 need to specify these variables if CMake was unable to locate something. This is indicated by a value ending in NOTFOUND.
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.
16.7 Boost Libraries
In most cases, if Boost is not automatically found, setting the BOOST_ROOT variable is enough. If it is not, you can specify the header and library directories individually. You can also provide the full pathname to a specific compiled library if it cannot be found in the library directory or its name is non-standard.
By default, when Boost binary libraries are needed, the shared versions are used if present. You can set the variable CGAL_Boost_USE_STATIC_LIBS to ON if you want to link with static versions explicitly.
On Windows, if you link with Boost shared libraries, you must ensure that the .dll files are found by the dynamic linker, at run time. For example, you can add the path to the Boost .dll to the PATH environment variable.
Variable | Description | Type |
|---|---|---|
BOOST_ROOT[6] | 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 |
16.8 GMP and MPFR Libraries
Under Windows, auto-linking is used, so only the directory containing the libraries 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 and of Mpfr will be disabled.
Variable | Description | Type |
|---|---|---|
WITH_GMP | Indicates whether to search and use Gmp/Mpfr or not | CMake |
GMP_DIR | Directory of Gmp default installation | Environment |
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 is also searched for, and you may specify the following variables:
Variable | Description | Type |
|---|---|---|
GMPXX_DIR | Directory of gmpxx default installation | Environment |
GMPXX_INCLUDE_DIR | Directory containing the gmpxx.h file | CMake |
GMPXX_LIBRARIES | Full pathname of the compiled Gmpxx library | CMake |
16.9 Qt3 Library
In most cases, if Qt3 is not automatically found, setting the QTDIR environment variable is sufficient. 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_EXECUTABLE | Full pathname to the moc executable of Qt3 | CMake |
QT3_UIC_EXECUTABLE | Full pathname to the uic executable of Qt3 | CMake |
16.10 Qt4 Library
The CMake scripts that search for Qt4 can use the introspection feature of the tool qmake included 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 if that one exists. One can alternatively set the CMake variable QT_QMAKE_EXECUTABLE. The following variables should be then assigned 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 library[7] | CMake |
QT_QMAKE_EXECUTABLE | Full pathname to the qmake executable of Qt4 | CMake |
QT_MOC_EXECUTABLE | Full pathname to the moc executable of Qt4 | CMake |
QT_UIC_EXECUTABLE | Full pathname to the uic executable of Qt4 | CMake |
16.11 LEDA Library
When the LEDA libraries are not automatically found, yet they are installed on 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, for example, 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_DIR | Directory of LEDA default installation | Environment |
LEDA_INCLUDE_DIR | Directory containing the file LEDA/system/basic.h | CMake |
LEDA_LIBRARIES | Directory containing the compiled LEDA libraries | CMake |
LEDA_INC_DIR | Directory containing the file LEDA/system/basic.h | Environment |
LEDA_LIB_DIR | Directory containing the compiled LEDA libraries | Environment |
LEDA_LIBRARY_RELEASE | Full pathname to a release build of the LEDA library | CMake |
LEDA_LIBRARY_DEBUG | Full pathname to a debug build of the LEDA library | CMake |
LEDA_DEFINITIONS | Preprocessor definitions | CMake |
LEDA_CXX_FLAGS | Compiler flags | CMake |
LEDA_LINKER_FLAGS | Linker flags | CMake |
16.12 MPFI Library
CGAL provides a number type based on this library, but the CGAL library itself does not depend on Mpfi. This means that this library must be configured when compiling an application that uses the above number type.
When Mpfi files are not on the standard path, the locations of the headers and library files must be specified by using environment variables.
Variable | Description | Type |
|---|---|---|
MPFI_DIR | Directory of MPFI default installation | Environment |
MPFI_INCLUDE_DIR | Directory containing the mpfi.h file | CMake |
MPFI_INC_DIR | Idem | Environment |
MPFI_LIBRARIES_DIR | Directory containing the compiled Mpfi library | CMake |
MPFI_LIB_DIR | Idem | Environment |
MPFI_LIBRARIES | Full pathname of the compiled Mpfi library | CMake |
16.13 RS and RS3 Library
As said before, only the CGAL univariate algebraic kernel depends on the library Rs. As the algebraic kernel is not compiled as a part of the CGAL library, this library is not detected nor configured at installation time.
CMake will try to find Rs in the standard header and library directories. When it is not automatically detected, the locations of the headers and library files must be specified using environment variables.
Rs needs Gmp 4.2 or later and Mpfi 1.3.4 or later. The variables related to the latter library may also need to be defined.
Variable | Description | Type |
|---|---|---|
RS_DIR | Directory of Rs default installation | Environment |
RS_INCLUDE_DIR | Directory containing the rs_exports.h file | CMake |
RS_INC_DIR | Idem | Environment |
RS_LIBRARIES_DIR | Directory containing the compiled Rs library | CMake |
RS_LIB_DIR | Idem | Environment |
RS_LIBRARIES | Full pathname of the compiled Rs library | CMake |
Similar variables exist for Rs3.
Variable | Description | Type |
|---|---|---|
RS3_DIR | Directory of Rs3 default installation | Environment |
RS3_INCLUDE_DIR | Directory containing the file rs3_fncts.h file | CMake |
RS3_INC_DIR | Idem | Environment |
RS3_LIBRARIES_DIR | Directory containing the compiled Rs3 library | CMake |
RS3_LIB_DIR | Idem | Environment |
RS3_LIBRARIES | Full pathname of the compiled Rs3 library | CMake |
16.14 NTL Library
Some polynomial computations in CGAL's algebraic kernel are speed up when Ntl is available. As the algebraic kernel is not compiled as a part of the CGAL library, this library is not detected nor configured at installation time.
CMake will try to find Ntl in the standard header and library directories. When it is not automatically detected, the locations of the headers and library files must be specified using environment variables.
Variable | Description | Type |
|---|---|---|
NTL_DIR | Directory of NTL default installation | Environment |
NTL_INCLUDE_DIR | Directory containing the NTL/ZZX.h file | CMake |
NTL_INC_DIR | Idem | Environment |
NTL_LIBRARIES_DIR | Directory containing the compiled Ntl library | CMake |
NTL_LIB_DIR | Idem | Environment |
NTL_LIBRARIES | Full pathname of the compiled Ntl library | CMake |
16.15 Eigen Library
Eigen is a header-only template library. Only the directory containing the header files of Eigen 3.1 (or greater) is needed.
Variable | Description | Type |
|---|---|---|
EIGEN3_DIR | Directory of EIGEN default installation | Environment |
EIGEN3_INCLUDE_DIR | Directory containing the file signature_of_eigen3_matrix_library | CMake |
EIGEN3_INC_DIR | Idem | Environment |
16.16 QGLViewer Library
Some demos require the GLViewer library.
In most cases, if QGLViewer is not automatically found, setting the QGLVIEWERROOT environment variable is sufficient. 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 QGLViewer 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 |
16.17 ESBTL Library
One skin surface example requires the Esbtl library in order to read Pdb files.
If Esbtl is not automatically found, setting the ESBTL_INC_DIR environment variable is sufficient.
Variable | Description | Type |
|---|---|---|
ESBTL_DIR | Directory of ESBTL default installation | Environment |
ESBTL_INC_DIR | Directory containing the ESBTL/default.h file | Environment |
ESBTL_INCLUDE_DIR | Directory containing the ESBTL/default.h file | CMake |
16.18 TBB Library
If Tbb is not automatically found, the user must set the TBBROOT environment variable. On Windows, TBBROOTbintbbvars.bat <arch> <vs> must be run (running tbbvars.bat without args shows the available parameter values). On other platforms, the environment variable TBB_ARCH_PLATFORM=<arch>/<kernel> must be set: <arch> is ia32 or intel64 and <linux_kernel_or_gcc_version> is what is used in
Variable | Description | Type |
|---|---|---|
TBBROOT | Directory of Tbb default installation | Environment |
TBB_INCLUDE_DIRS | Directory containing the tbb/tbb.h file | CMake |
TBB_LIBRARY_DIRS | Directory(ies) containing the compiled TBB libraries | CMake |
TBB_LIBRARIES | Full pathnames of the compiled TBB libraries (both release and debug versions, using "optimized" and "debug" CMake keywords). Note that if the debug versions are not found, the release versions will be used instead for the debug mode. | CMake |
TBB_RELEASE_LIBRARY | Full pathname of the compiled TBB release library | CMake |
TBB_MALLOC_RELEASE_LIBRARY | Full pathname of the compiled TBB release malloc library | CMake |
TBB_DEBUG_LIBRARY | Full pathname of the compiled TBB debug library | CMake |
TBB_MALLOC_DEBUG_LIBRARY | Full pathname of the compiled TBB debug malloc library | CMake |
TBB_MALLOCPROXY_DEBUG_LIBRARY | Full pathname of the compiled TBB debug malloc_proxy library (optional) | CMake |
TBB_MALLOCPROXY_RELEASE_LIBRARY | Full pathname of the compiled TBB release malloc_proxy library (optional) | CMake |
17 Compiler Workarounds
A number of boolean flags are used to workaround compiler bugs and limitations. They all start with the prefix CGAL_CFG. These flags are used to work around compiler bugs and limitations. For example, the flag CGAL_CFG_NO_CPP0X_LONG_LONG denotes that the compiler does not know the type long long.
For each installation 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-4.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.
18 Compiler Optimizations
By default CMake generates makefiles for Release mode, with optimization flags switched on, and vcproj files for Release and Debug modes.
- ^EGC :: Home
- ^GCC, the GNU Compiler Collection- GNU Project
- ^Intel® oneAPI Toolkits
- ^Visual Studio: IDE and Code Editor for Software Developers and Teams
- ^CGAL_Core is not part of CGAL, but a custom version of the Core library distributed by CGAL for the user convenience and it has it's own license.
- ^The environment variable can be spelled either
BOOST_ROOTorBOOSTROOT - ^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.
