songsenand
/
cgal
mirror of https://github.com/CGAL/cgal
1
0
Fork 0
Code Issues Packages Projects Releases Wiki Activity
cgal/Documentation/doc/Installation.txt

2277 lines
70 KiB
Plaintext
Raw Blame History

/*!
\page installation Installation
\cgalAutoToc
\authors Eric Berberich, Joachim Reichel, and Fernando Cacciola
\section installation_introduction Introduction
This document describes how to install \cgal on Windows, Unix-like systems, and MacOS X.
Ideally, setting up \cgal amounts to:
<PRE>
cd CGAL-x.y # go to \cgal directory
cmake . # configure \cgal
make # build the \cgal libraries
</PRE>
Compiling an example shipped with \cgal is similar simple:
<PRE>
cd examples/Straight_skeleton_2 # go to an example directory
cmake -DCGAL_DIR=$HOME/CGAL-x.y . # configure the examples
make # build the examples
</PRE>
Compiling an own non-shipped program is also close:
<PRE>
cd /path/to/program
cgal_create_CMakeLists -s executable
cmake -DCGAL_DIR=$HOME/CGAL-x.y .
make
</PRE>
where the second line creates a `CMakeLists.txt` file (check
its options in Section \ref seccreate_cgal_CMakeLists for various details).
In a less ideal world, you probably have to install CMake, a makefile
generator, and third party libraries. That is what this manual is about.
\section secprerequisites Prerequisites
Installing \cgal requires a few components to be installed ahead: a
supported compiler (see Section \ref seccompilers, CMake, \sc{Boost}, and at least \sc{Gmp}, and \sc{Mpfr}; see
Section \ref secessential3rdpartysoftware for more details on
essential third party software.
\section secshippedcgal OS-shipped CGAL
Some operating systems with package managers offer \cgal and its
essential third party software through the manager,
for instance, Mac OS X, or some Linux distribution (e.g. Debian).
\subsection sseccgalmacosxe CGAL on MAC OS X
For instance, use macports in the following way:
<PRE>
sudo port install cgal
</PRE>
or if Qt4 demos are desired
<PRE>
sudo port install cgal +qt4 +universal +demos
</PRE>
The setup is similar for homebrew.
\subsection sseccgaldebian CGAL on Linux
For instance in debian/Ubuntu, use apt-get in the following way:
<PRE>
sudo apt-get install libcgal-dev
</PRE>
To get the demos use
<PRE>
sudo apt-get install libcgal-demo
</PRE>
Check the \cgal-FAQ for source repository of newest releases.
On other distributions, please consult your package manager documentation.
\section secgettingcgal Downloading CGAL
You can obtain the \cgal library from
<A HREF="http://www.cgal.org/download.html">http://www.cgal.org/download.html</A>
and install it yourself.
After you have downloaded the file `CGAL-x.y.tar.gz` containing the
\cgal sources, you have to unpack it. Under a Unix-like shell, use the
command:
<PRE>
tar xzf `CGAL-x.y`.tar.gz
</PRE>
When you are on Windows you may download and run `CGAL-x.y-Setup.exe`. It
is a self extracting executable that installs the \cgal source, and that allows
you to select and download some precompiled third party libraries.
In both cases the directory `CGAL-x.y` will be created. This directory
contains the following subdirectories:
<CENTER>
<TABLE CELLSPACING=5 BORDER=2>
<TR>
<TD ALIGN=LEFT NOWRAP>
<B>directory</B>
<TD ALIGN=LEFT NOWRAP>
<B>contents</B>
<TR>
<TD ALIGN=LEFT NOWRAP>
`auxiliary`
<TD ALIGN=LEFT NOWRAP>
precompiled \sc{Gmp} and \sc{Mpfr} for Windows
<TR>
<TD ALIGN=LEFT NOWRAP>
`cmake/modules`
<TD ALIGN=LEFT NOWRAP>
modules for finding and using libraries
<TR>
<TD ALIGN=LEFT NOWRAP>
`config`
<TD ALIGN=LEFT NOWRAP>
configuration files for install script
<TR>
<TD ALIGN=LEFT NOWRAP>
`demo`
<TD ALIGN=LEFT NOWRAP>
demo programs (most of them need \sc{Qt}, geomview or other third-party products)
<TR>
<TD ALIGN=LEFT NOWRAP>
`doc_html`
<TD ALIGN=LEFT NOWRAP>
documentation (HTML)
<TR>
<TD ALIGN=LEFT NOWRAP>
`examples`
<TD ALIGN=LEFT NOWRAP>
example programs
<TR>
<TD ALIGN=LEFT NOWRAP>
`include`
<TD ALIGN=LEFT NOWRAP>
header files
<TR>
<TD ALIGN=LEFT NOWRAP>
`scripts`
<TD ALIGN=LEFT NOWRAP>
some useful scripts (e.g. for creating CMakeLists.txt files)
<TR>
<TD ALIGN=LEFT NOWRAP>
`src`
<TD ALIGN=LEFT NOWRAP>
source files
</TABLE>
</CENTER>
The directories `include/CGAL/CORE` and `src/CGALCore` contain a
distribution of the \sc{Core} library\cgalFootnote{<A HREF="http://www.cs.nyu.edu/exact/">`http://www.cs.nyu.edu/exact/`</A>} version 1.7 for
dealing with algebraic numbers. \sc{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. \sc{OpenNL} is not part
of \cgal and has its own license.
The only documentation shipped with \cgal sources is the present
installation manual. The \cgal manual must be downloaded separately from
<A HREF="http://www.cgal.org/download.html">`http://www.cgal.org/download.html`</A>.
\section seccompilers Supported Compilers
In order to build the \cgal libraries, you need a \cpp compiler.
\cgal x.y is supported for the following compilers/operating systems:
<CENTER>
<TABLE CELLSPACING=5 BORDER=2>
<TR>
<TD ALIGN=LEFT NOWRAP>
<B>compiler</B>
<TD ALIGN=LEFT NOWRAP>
<B>operating system</B>
<TR>
<TD ALIGN=LEFT NOWRAP>
\sc{Gnu} `g++` 3.4 or later<A HREF="#Footnote_1"><SUP>1</SUP></A>
<TD ALIGN=LEFT NOWRAP>
Linux / MacOS X
<TR>
<TD ALIGN=LEFT NOWRAP>
<TD ALIGN=LEFT NOWRAP>
\sc{MS} Windows 95/98/2000/XP/NT4
<TR>
<TD ALIGN=LEFT NOWRAP>
\sc{Intel} `C++` 11.0 or later<A HREF="#Footnote_2"><SUP>2</SUP></A>
<TD ALIGN=LEFT NOWRAP>
Linux
<TR>
<TD ALIGN=LEFT NOWRAP>
\sc{MS} Visual `C++` 9.0, 10.0 (\sc{Visual Studio 2008 and 2010})<A HREF="#Footnote_3"><SUP>3</SUP></A>
<TD ALIGN=LEFT NOWRAP>
\sc{MS} Windows 95/98/2000/XP/NT4/Vista/7
</TABLE>
</CENTER>
\section secconfigwithcmake Configuring CGAL with CMake
In order to configure, build, and install the \cgal libraries, examples and
demos, you need CMake, a cross-platform "makefile generator".
If CMake is not installed already you can obtain it from <A HREF="http://www.cmake.org/">`http://www.cmake.org/`</A>.
CMake version 2.6.2 or higher is required. On Windows, CMake
version 2.8.6 or higher is required, for a proper support of DLL's
generation.
This manual explains only those features of
CMake which are needed in order to build \cgal. Please refer to the
CMake documentation at <A HREF="http://www.cmake.org/">`http://www.cmake.org/`</A> for further details.
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, and
which \cgal libraries you want to build. Gathering
all this information is called <I>configuration</I>.
The end of the process is marked by the generation of a makefile or a
Visual \cpp solution and project file that you can use to build \cgal.
\subsection installation_configuring_gui Configuring CGAL with the CMake Gui
The simplest way to start the configuration is to run the graphical
user interface of CMake. We recommend to use `cmake-gui`. It
is available on many platforms as of CMake version 2.6. You must pass as
argument the root directory of \cgal. For example:
<PRE>
cd `CGAL-x.y`
cmake-gui . # Notice the dot to indicate the current directory.
</PRE>
After `cmake-gui` opens, press 'Configure'.
A dialog will pop up and you will have to choose what shall gets generated.
After you have made your choice and pressed 'Finish', you will see
the output of configuration tests in the lower portion of the application.
When these tests are done, you will see many
red entries in the upper portion of the application. Just ignore them and press '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 'Generate'. Once this is
done, you can quit `cmake-gui`.
\subsection installation_configuring_cmd Configuring CGAL with the cmake command-line tool
Alternatively, you can run the command-line tool called
`cmake`. You pass as argument the root directory of
\cgal. For example:
<PRE>
cd `CGAL-x.y`
cmake . # Notice the dot to indicate the current directory.
</PRE>
The very first thing CMake does is to detect the compiler to use. This
detection is performed by a special CMake module called a
<I>generator</I>.
A CMake generator understands the build requirements for a
particular compiler/linker and generates the necessary files for that. For
example, the <I>UNIX Makefiles</I> generator understands the GNU chain
of tools (\gcc, ld etc.) and produces makefiles, which can be used to build a
target by a simple call to `make`. Likewise, the <I>Visual Studio
2010</I> 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 <I>NMakefiles</I> 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, as generators are hardcoded into CMake, and additional
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 \cpp 11.0 on a 64bit machine:
<PRE>
cd `CGAL-x.y`
cmake -G"Visual Studio 11 Win64" .
</PRE>
In other cases, however, the generator doesn't directly identify a
specific compiler but a chain of tools.
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
specify the desired compiler in the call to CMake, as in this example:
<PRE>
cd `CGAL-x.y`
cmake -DCMAKE_CXX_COMPILER:FILEPATH=g++-4.7 .
</PRE>
CMake maintains configuration parameters in so-called <I>cmake variables</I>, like the `CMAKE_CXX_COMPILER`
in the example above. These variables <I>are not environment variables</I> but <I>CMake variables</I>. 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 need to be explicitly defined.
\cgalAdvanced CMake keeps the variables that a user can manipulate in a
so-called <I>CMake cache</I>, a simple text file named
`CMakeCache.txt`, whose entries are of the form
`VARIABLE:TYPE=VALUE`. Advanced users can manually edit this file,
instead of going through the interactive configuration session.
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. The
purpose of this file is explained below.
\section seclibraries CGAL Libraries
\cgal is split into five libraries. During configuration, you can select the libraries that
you would like to build by setting a CMake variable of the form <TT>WITH_<library></TT>. By default all
are switched `ON`. All activated libraries are build after
configuration; see \ref secbuilding
We next list the libraries and essential 3rd party software
(see \ref secessential3rdpartysoftware) for each library:
<CENTER>
<TABLE CELLSPACING=5 BORDER=2>
<TR>
<TD ALIGN=LEFT NOWRAP>
<B>library</B>
<TD ALIGN=LEFT NOWRAP>
<B>CMake variable</B>
<TD ALIGN=LEFT NOWRAP>
<B>functionality</B>
<TD ALIGN=LEFT NOWRAP>
<B>dependencies</B>
<TR>
<TD ALIGN=LEFT NOWRAP>
`%CGAL`
<TD ALIGN=LEFT NOWRAP>
<I>none</I>
<TD ALIGN=LEFT NOWRAP>
Main library
<TD ALIGN=LEFT NOWRAP>
\sc{Gmp}, \sc{Mpfr}, \sc{Boost} (headers)
<TR>
<TD ALIGN=LEFT NOWRAP>
<TD ALIGN=LEFT NOWRAP>
<TD ALIGN=LEFT NOWRAP>
<TD ALIGN=LEFT NOWRAP>
and Boost.Thread (library)
<TR>
<TD ALIGN=LEFT NOWRAP>
`CGAL_Core`
<TD ALIGN=LEFT NOWRAP>
`WITH_CGAL_Core`
<TD ALIGN=LEFT NOWRAP>
The CORE library for algebraic numbers.<A HREF="#Footnote_15"><SUP>15</SUP></A>
<TD ALIGN=LEFT NOWRAP>
\sc{Gmp} and \sc{Mpfr}
<TR>
<TD ALIGN=LEFT NOWRAP>
`CGAL_ImageIO`
<TD ALIGN=LEFT NOWRAP>
`WITH_CGAL_ImageIO`
<TD ALIGN=LEFT NOWRAP>
Utilities to read and write image files
<TD ALIGN=LEFT NOWRAP>
\sc{OpenGL}, \sc{zlib}, \sc{Vtk}(optional)
<TR>
<TD ALIGN=LEFT NOWRAP>
`CGAL_Qt3`
<TD ALIGN=LEFT NOWRAP>
`WITH_CGAL_Qt3`
<TD ALIGN=LEFT NOWRAP>
`CGAL::Qt_widget` used by \sc{Qt}3-based demos
<TD ALIGN=LEFT NOWRAP>
\sc{Qt}3 and \sc{OpenGL}
<TR>
<TD ALIGN=LEFT NOWRAP>
`CGAL_Qt4`
<TD ALIGN=LEFT NOWRAP>
`WITH_CGAL_Qt4`
<TD ALIGN=LEFT NOWRAP>
`QGraphicsView` support for \sc{Qt}4-based demos
<TD ALIGN=LEFT NOWRAP>
\sc{Qt}4 and \sc{OpenGL}
</TABLE>
</CENTER>
\subsection installation_debug Debug vs. Release
The CMake variable `CMAKE_BUILD_TYPE` indicates how to build
the libraries. It accepts the values `Release` or
`Debug`. The default is `Release` and should be kept, unless you want to debug
your program.
This is not an issue for solution/project files, as there the user selects the build type from within the IDE.
\subsection installation_static Static vs. Shared Libraries
Shared libraries, also called <I>dynamic-link libraries</I>, are built by default
(`.dll` on Windows, `.so` on Linux, `.dylib` on MacOS). You
can choose to produce static libraries instead by setting the CMake
variable `BUILD_SHARED_LIBS` to `FALSE`. If you use
`cmake-gui`, a tick box for that variable is available to set it.
These setting affect the variants of third-party libraries (see next
section) selected whenever the choice is available.
\section secessential3rdpartysoftware Essential Third Party Libraries
The focus of \cgal is on geometry, and we rely on other
highly specialized libraries and software for non-geometric issues,
for instance, for numeric solvers, or visualization. We first list software
that is essential to build (all) libraries of \cgal, that is,
this software must be found during the configuration of \cgal for an
actived library of \cgal (i.e.\ <TT>WITH_<library>=ON</TT>);
see \ref sec3partysoftwareconfig to specify the location of 3rd
party software.
The libraries \stl (shipped with any compiler) and \sc{Boost} are essential to all components (i.e.\ libCGAL,
libCGAL_Core, libCGAL_ImageIO, libCGAL_Qt3 and libCGAL_Qt4).
\subsection thirdpartystl Standard Template Library (STL)
\cgal heavily uses the \stl, and in particular adopted
many of its design ideas. You can find online
documentation for the \stl at various web sites, for instance,
<A HREF="http://www.sgi.com/tech/stl/">`http://www.sgi.com/tech/stl/`</A>, <A HREF="http://www.cplusplus.com/reference/">`http://www.cplusplus.com/reference/`</A>,
or <A HREF="http://msdn.microsoft.com/en-us/library/1fe2x6kt(VS.100).aspx">`http://msdn.microsoft.com/en-us/library/1fe2x6kt(VS.100).aspx`</A>.
The \stl comes with the compiler, so there is nothing to install.
\subsection thirdpartyBoost Boost
The \sc{Boost} libraries are a set of portable C++ source libraries. Most of
\sc{Boost} libraries are header-only, but a few of them need to be compiled or
installed as binaries.
\cgal requires the \sc{Boost} libraries. In particular the header files
and the threading library (`Boost.Thread` and
`Boost.System` binaries). Version 1.39 (or higher) are needed.
On Windows, as auto-linking is used, you also need the binaries of
`Boost.Serialization` and `Boost.DateTime`, but the
dependency is artificial and used only at link-time: the \cgal libraries do
not depend on the DLL's of those two libraries.
In \cgal some demos and examples depend on `Boost.Program_options`.
In case the \sc{Boost} libraries are not installed on your system already, you
can obtain them from <A HREF="http://www.boost.org/">`http://www.boost.org/`</A>. For Windows you can download an
installer from <A HREF="http://www.boostpro.com/download/">`http://www.boostpro.com/download/`</A>.
Since `Boost.Thread` is required, make sure to either install the precompiled
libraries for your compiler or build `libboost-thread` and `libboost-system`.
As on Windows there is no canonical directory for where to find
\sc{Boost}, we recommend that you define the environment variable
`BOOST_ROOT` and set it to where you have installed \sc{Boost}, e.g.,
<A HREF="C:\boost\boost_1_41_0">`C:\boost\boost_1_41_0`</A>.
\subsection thirdpartyMPFR Gmp and Mpfr
The components libCGAL, libCGAL_Core, libCGAL_Qt3 and libCGAL_Qt4 require
\sc{Gmp} and \sc{Mpfr} which are libraries for multi precision integers and rational numbers,
and for multi precision floating point numbers.
\cgal combines floating point arithmetic with exact arithmetic,
in order to be efficient and reliable. \cgal has a built-in
number type for that, but \sc{Gmp} and \sc{Mpfr} provide a faster
solution, and we recommend to use them.
Having \sc{Gmp} version 4.2 or higher and \sc{Mpfr} version 2.2.1 or higher
installed is recommended. These libraries can be obtained from
<A HREF="http://gmplib.org/">`http://gmplib.org/`</A> and <A HREF="http://www.mpfr.org/">`http://www.mpfr.org/`</A>, respectively.
As Visual \cpp is not properly
supported by the \sc{Gmp} and \sc{Mpfr} projects, we provide precompiled versions
of \sc{Gmp} and \sc{Mpfr}, which can be downloaded with the installer
`CGAL-x.y-Setup.exe`.
\subsection thirdpartyzlib zlib
\sc{zlib} is a data compression library, and is essential for the component libCGAL_ImageIO.
In \cgal this library is used in the examples of the \ref PkgSurfaceMesher3 package.
If it is not already on your system,
for instance, on Windows, you can download it from <A HREF="http://www.zlib.net/">`http://www.zlib.net/`</A>.
\subsection thirdpartyOpenGL OpenGL
\sc{OpenGL} (Open Graphics Library) provides an API for applications that
produce 2D and 3D computer graphics.
In \cgal the library is essential for the components libCGAL_Qt3 and
libCGAL_Qt4, as well as libCGAL_ImageIO and for various demos.
Typically, \sc{OpenGL} is preinstalled on systems; if not, it can be
downloaded from <A HREF="http://www.opengl.org/">`http://www.opengl.org/`</A>.
\subsection thirdpartyQt Qt3 and Qt4
Qt is a cross-platform application and UI framework.
The component libCGAL_Qt3 requires \sc{Qt}3 installed on your system, while
the component libCGAL_Qt4 requires \sc{Qt}4 installed on your system.
In case \sc{Qt} is not yet installed on your system, you can download
it from <A HREF="http://qt-project.org/">`http://qt-project.org/`</A>.
Older demos of \cgal use libCGAL_Qt3 and \sc{Qt}3, while newer and newly
developed demos require libCGAL_Qt4 and \sc{Qt}4.
Having \sc{Qt}4 version 4.3.0 or higher is recommended.
\section installation_examples CGAL Examples and Demos
\cgal is distributed with a large collection of examples and demos. By default, these are <B>not</B> configured along with
the \cgal libraries, unless you set the variables `WITH_examples=ON` and/or `WITH_demos=ON`.
Nevertheless, even when configured with \cgal, they are not automatically built along with the libraries.
You must build the `examples` or `demos` targets (or IDE projects) explicitly.
If you do not plan to compile any demos, you might skip some of the essential libraries (as \sc{Qt} or
\sc{OpenGL}), as the corresponding \cgal-libraries are not linked. But for
your own demos you might need these \cgal-libraries.
\section secoptional3rdpartysoftware Optional Third Party Libraries
Optional 3rd party software can be used by \cgal for various reasons:
Usually certain optional libraries are required to build examples and
demos shipped with \cgal\ or to build your own project using \cgal.
Another reason is to speed up basic tasks.
In order to support these goals, all optional libraries can be <i>prepared to be
used with \cgal</I> while configuring \cgal, just in the same way as
essential libraries are configured. Whenever building an example or a
demo (or your own executable), these <I>preconfigured</I> libraries
are available when using \cgal.
\subsection thirdpartyLeda Leda
\leda is a library of efficient data structures and
algorithms. Like \sc{Core}, \leda offers a real number data type.
In \cgal this library is optional, and its number types can
be used as an alternative to \sc{Gmp}, \sc{Mpfr}, and \sc{Core}.
Free and commercial editions of \leda are available from <A HREF="http://www.algorithmic-solutions.com/leda/index.html">`http://www.algorithmic-solutions.com/leda/index.html`</A>.
\subsection thirdpartyMPFI Mpfi
\sc{Mpfi} provides arbitrary precision interval arithmetic with intervals
represented using \sc{Mpfr} reliable floating-point numbers.
It is based on the libraries \sc{Gmp} and \sc{Mpfr}.
In the setting of \cgal, this library is
optional: it is used by some models of the
\ref PkgAlgebraicKerneld "Algebraic Kernel".
\sc{Mpfi} can be downloaded from <A HREF="http://mpfi.gforge.inria.fr/">`http://mpfi.gforge.inria.fr/`</A>. Version 1.4 or higher is recommended.
\subsection thirdpartyRS3 Rs and Rs3
\sc{Rs} (Real Solutions) is devoted to the study of the real roots of
polynomial systems with a finite number of complex roots (including
univariate polynomials). In \cgal, \sc{Rs} is used by one model of the
\ref PkgAlgebraicKerneld "Algebraic Kernel".
\sc{Rs} is freely distributable for non-commercial use. You can download it
from <a href="http://vegas.loria.fr/rs/">`http://vegas.loria.fr/rs/`</a>. Actually, the \sc{Rs} package also includes \sc{Rs3}, the
successor of \sc{Rs}, which is used in conjunction with it.
The libraries \sc{Rs} and \sc{Rs3} need \sc{Mpfi}, which can be downloaded from
<A HREF="http://mpfi.gforge.inria.fr/">`http://mpfi.gforge.inria.fr/`</A>.
Rs is freely distributable for non-commercial use. You can download it
from <A HREF="http://vegas.loria.fr/rs/">`http://vegas.loria.fr/rs/`</A>.
The library Rs needs \sc{Mpfi}, which can be downloaded from <A HREF="http://mpfi.gforge.inria.fr/">`http://mpfi.gforge.inria.fr/`</A>.
Version 1.4 or higher is recommended.
The successor of Rs is called Rs3. It less restrictive when it comes
to licencing and also contains improved and more efficient interfaces.
Mainly parts in \cgal's algebraic kernel require Rs3.
\subsection thirdpartyNTL Ntl
\sc{Ntl} provides data structures and algorithms for signed, arbitrary
length integers, and for vectors, matrices, and polynomials over the
integers and over finite fields. The optional library \sc{Ntl} is used by \cgal
to speed up operations of the Polynomial package, such as GCDs. It is recommended to install \sc{Ntl} with support from \sc{Gmp}.
\sc{Ntl} can be downloaded from <A HREF="http://www.shoup.net/ntl/">`http://www.shoup.net/ntl/`</A>. Version 5.1 or higher is recommended.
\subsection thirdpartyEigen Eigen
\sc{Eigen} is a `C++` template library for linear algebra. \sc{Eigen} supports all
matrix sizes, various matrix decomposition methods and sparse linear solvers.
In \cgal, \sc{Eigen} provides sparse linear solvers in the \ref PkgSurfaceReconstructionFromPointSets
and the \ref PkgSurfaceParameterization packages.
In addition, \sc{Eigen} also provides singular value decomposition for the \ref PkgJet_fitting_3
and the \ref PkgRidges_3 packages.
The \sc{Eigen} web site is <A HREF="http://eigen.tuxfamily.org">`http://eigen.tuxfamily.org`</A>.
\subsection thirdpartylibQGLViewer libQGLViewer
libQGLViewer is a 3D widget based on \sc{Qt} 4's `QGLWidget`.
In \cgal some 3D demos are based on libQGLViewer.
It can be downloaded from <A HREF="http://www.libqglviewer.com/">`http://www.libqglviewer.com/`</A>.
\subsection thirdpartyCoin Coin3D
\sc{Coin3D} is an implementation of Open Inventor.
In \cgal, \sc{Coin3D} is used in the demo
of the \ref PkgKds package.
You can download it from <A HREF="http://www.coin3d.org/">`http://www.coin3d.org/`</A>.
\subsection thirdpartyESBTL Estbl
The \sc{Estbl} (Easy Structural Biology Template Library) is a library that allows
the handling of \sc{Pdb} data.
In \cgal the \sc{Estbl} is used in an example of the
\ref PkgSkinSurface3 package.
It can be downloaded from <A HREF="http://esbtl.sourceforge.net/">`http://esbtl.sourceforge.net/`</A>.
\section secbuilding 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 <I>targets</I>, one per library, and a default global target corresponding
to all the libraries.
For example, in a \sc{Unix}-like environment the default generator produces
makefiles. You can use the `make` command-line tool for the
succeeding build step as follows:
<PRE>
cd `CGAL-x.y`
# build all the selected libraries at once
make
</PRE>
The resulting libraries are placed in the subdirectory `lib` under `<CMAKE_BINARY_DIR>`
(which is `CGAL-x.y` 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 \sc{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 \sc{Ide}.
Alternatively, you can build it with the command line version of the
\sc{Visual Studio Ide}:
<PRE>
devenv CGAL.sln /Build Debug
</PRE>
The "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).
\cgalAdvanced 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
<I>after</I> the \cgal libraries have been successfully built.
The targets `examples` and `demos` include themselves all the targets
for examples and demos respectively.
<PRE>
# 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
</PRE>
\cgalAdvanced 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>`.
\section secinstalling 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 <A HREF="/usr/include">`/usr/include`</A> and <A HREF="/usr/lib">`/usr/lib`</A> on \sc{Unix}-like
operating systems or <A HREF="C:/Program Files/">`C:/Program Files/`</A> on Windows. The process
of placing or copying the library elements into its standard location
is sometimes referred to as <I>Installation</I> and it is a
postprocessing step after the build step.
CMake carries out the installation by producing a build target named <I>install</I>.
The following example shows a typical session from configuration to
installation in a \sc{Unix}-like environment:
<PRE>
cd `CGAL-x.y`
cmake . # configure
make # compile
make install # install
</PRE>
If 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 <I>"build"</I> to execute the installation step.
\cgalAdvanced The files are copied into a directory tree relative to the <I>installation directory</I> determined by the
CMake variable `CMAKE_INSTALL_PREFIX`. This variable defaults to `/usr/local` under \sc{Unix}-like operating systems
and <A HREF="C:\ProgramFiles">`C:\Program Files`</A> under Windows. If you want to install to a different location, you must override that CMake
variable explicitly <I>at the configuration time</I> and not when executing the install step.
The file `CGALConfig.cmake` is installed by default in
`$CMAKE_INSTALLED_PREFIX/lib/CGAL-x.y`.
\section installation_example_configuration 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`:
<PRE>
cmake -DWITH_examples=OFF -DWITH_demos=OFF -DCMAKE_BUILD_TYPE=Release
/path/to/unpacked/CGAL-tarball/
</PRE>
<PRE>
-- 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/
</PRE>
\section seccmakeoutofsource 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 <I>out-of-source configuration</I>, as opposite to an <I>in-source
configuration</I>, as showed in the previous sections.
You can, for example, generate subdirectories `CGAL-x.y``/cmake/platforms/debug` and
`CGAL-x.y``/cmake/platforms/release` for two configurations, respectively:
<PRE>
mkdir `CGAL-x.y`/cmake/platforms/debug
cd `CGAL-x.y`/cmake/platforms/debug
cmake -DCMAKE_BUILD_TYPE=Debug ../../..
mkdir `CGAL-x.y`/cmake/platforms/release
cd `CGAL-x.y`/cmake/platforms/release
cmake -DCMAKE_BUILD_TYPE=Release ../../..
</PRE>
\section installation_configuring_using Configuring and Building Programs Using CGAL
Ideally, configuring and compiling a demo/example/program amounts to
<PRE>
cd `CGAL-x.y`/examples/Straight_skeleton_2
cmake -DCGAL_DIR=$HOME/`CGAL-x.y` .
make
</PRE>
In 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:
<PRE>
cd /path/to/program
cgal_create_CMakeLists -s executable
cmake -DCGAL_DIR=$HOME/`CGAL-x.y` .
make
</PRE>
In 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 \ref seccmakeoutofsource.
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.
\subsection installation_creating 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:
\subsection seccreate_cgal_CMakeLists cgal_create_CMakeLists
The Bourne-shell script `cgal_create_CMakeLists.txt` resides in the
`CGAL-x.y/scripts` directory. It can be used to create
`CMakeLists.txt` files for compiling \cgal applications. Executing
`cgal_create_CMakeLists.txt` in an application directory creates a
`CMakeLists.txt` containing rules to build the contained
application(s). Three command line options determine details of the
configuration.
<DL>
<DT><B>`-s source`</B><DD> If this parameter is given the script will
create <B>a single executable</B> 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 <B>one executable for each given
source file</B>.
<DT><B>`-c com1:com2:...`</B><DD> 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`
<DT><B>`-b boost1:boost2:...`</B><DD> Lists components ("boost1",
"boost2") of \sc{Boost} to which the executable(s) should be
linked. Valid options are, for instance, "filesystem" or "program_options".
</DL>
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.
\subsection seccreate_cgal_cmake_script cgal_create_cmake_script
\deprecated For backward-compatibility we still provide the
Bourne-shell script `cgal_create_cmake_script` that is
contained in the `CGAL-x.y/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. The script is deprecated,
as it only works for applications with a single course file that only
need libCGAL and libCGAL_Core.
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` (<i>Core</i>),
libCGAL_ImageIO (<i>ImageIO</i>) , libCGAL_Qt3 (<i>Qt3</i>) and libCGAL_Qt4
(<i>Qt4</i>) or optional 3rd party software such as <i>MPFI</i>, <i>RS3</i>.
A user is free to create the `CMakeLists.txt`
without calling the script (manual creation).
\subsection installation_custom 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 <I>very first</I> time
a program is configured, all the flags given by the CMake variables `CMAKE_*_FLAGS`
are <I>locked</I> 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 <I>inherited</I> values are then recorded in the current CMake cache for the program.
The flags are then <I>unlocked</I> 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.
\cgalAdvanced 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`.
\cgalAdvanced If you use the command line tool you can specify flags <I>directly</I> by setting the
controlling variable right up front:
\code{.sh}
cd CGAL-x.y
cmake -DCMAKE_BUILD_TYPE=Release -DCMAKE_CXX_FLAGS=-g .
cd CGAL-x.y/examples/Straight_skeleton_2
cmake -DCGAL_DIR=CGAL-x.y -DCMAKE_BUILD_TYPE=Debug -DCMAKE_CXX_FLAGS=-O2 -DCGAL_DONT_OVERRIDE_CMAKE_FLAGS=TRUE .
\endcode
\section installation_summary Summary of CGAL's Configuration Variables
Most configuration variables are not environment variables but
<I>CMake variables</I>. 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.
\subsection installation_component_selection Component Selection
The following boolean variables indicate which \cgal components to
configure and build. Their values can be ON or OFF.
<SMALL>
<TABLE CELLSPACING=5 BORDER=2>
<TR>
<TD ALIGN=LEFT NOWRAP>
<B>Variable</B>
<TD ALIGN=LEFT NOWRAP>
<B>Default value</B>
<TR>
<TD ALIGN=LEFT NOWRAP>
`WITH_examples`
<TD ALIGN=LEFT NOWRAP>
OFF
<TR>
<TD ALIGN=LEFT NOWRAP>
`WITH_demos`
<TD ALIGN=LEFT NOWRAP>
OFF
<TR>
<TD ALIGN=LEFT NOWRAP>
`WITH_CGAL_Core`
<TD ALIGN=LEFT NOWRAP>
ON
<TR>
<TD ALIGN=LEFT NOWRAP>
`WITH_CGAL_Qt3`
<TD ALIGN=LEFT NOWRAP>
ON
<TR>
<TD ALIGN=LEFT NOWRAP>
`WITH_CGAL_Qt4`
<TD ALIGN=LEFT NOWRAP>
ON
<TR>
<TD ALIGN=LEFT NOWRAP>
`WITH_CGAL_ImageIO`
<TD ALIGN=LEFT NOWRAP>
ON
</TABLE>
</SMALL>
\subsection installation_flags 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 <I>entirely</I> 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.
<SMALL>
<TABLE CELLSPACING=5 BORDER=2>
<TR>
<TD ALIGN=LEFT NOWRAP>
<B>Program</B>
<TD ALIGN=LEFT NOWRAP>
<B>Both Debug and Release</B>
<TD ALIGN=LEFT NOWRAP>
<B>Release only</B>
<TD ALIGN=LEFT NOWRAP>
<B>Debug Only</B>
<TR>
<TD ALIGN=LEFT NOWRAP>
C++ Compiler
<TD ALIGN=LEFT NOWRAP>
`CMAKE_CXX_FLAGS`
<TD ALIGN=LEFT NOWRAP>
`CMAKE_CXX_FLAGS_RELEASE`
<TD ALIGN=LEFT NOWRAP>
`CMAKE_CXX_FLAGS_DEBUG`
<TR>
<TD ALIGN=LEFT NOWRAP>
Linker (shared libs)
<TD ALIGN=LEFT NOWRAP>
`CMAKE_SHARED_LINKER_FLAGS`
<TD ALIGN=LEFT NOWRAP>
`CMAKE_SHARED_LINKER_FLAGS_RELEASE`
<TD ALIGN=LEFT NOWRAP>
`CMAKE_SHARED_LINKER_FLAGS_DEBUG`
<TR>
<TD ALIGN=LEFT NOWRAP>
Linker (static libs)
<TD ALIGN=LEFT NOWRAP>
`CMAKE_MODULE_LINKER_FLAGS`
<TD ALIGN=LEFT NOWRAP>
`CMAKE_MODULE_LINKER_FLAGS_RELEASE`
<TD ALIGN=LEFT NOWRAP>
`CMAKE_MODULE_LINKER_FLAGS_DEBUG`
<TR>
<TD ALIGN=LEFT NOWRAP>
Linker (programs)
<TD ALIGN=LEFT NOWRAP>
`CMAKE_EXE_LINKER_FLAGS`
<TD ALIGN=LEFT NOWRAP>
`CMAKE_EXE_LINKER_FLAGS_RELEASE`
<TD ALIGN=LEFT NOWRAP>
`CMAKE_EXE_LINKER_FLAGS_DEBUG`
</TABLE>
</SMALL>
\subsection installation_additional_flags Additional Compiler and Linker Flags
The following variables can be used to <I>add</I> flags without overriding the ones
defined by cmake.
<SMALL>
<TABLE CELLSPACING=5 BORDER=2>
<TR>
<TD ALIGN=LEFT NOWRAP>
<B>Program</B>
<TD ALIGN=LEFT NOWRAP>
<B>Both Debug and Release</B>
<TD ALIGN=LEFT NOWRAP>
<B>Release only</B>
<TD ALIGN=LEFT NOWRAP>
<B>Debug Only</B>
<TR>
<TD ALIGN=LEFT NOWRAP>
C++ Compiler
<TD ALIGN=LEFT NOWRAP>
`CGAL_CXX_FLAGS`
<TD ALIGN=LEFT NOWRAP>
`CGAL_CXX_FLAGS_RELEASE`
<TD ALIGN=LEFT NOWRAP>
`CGAL_CXX_FLAGS_DEBUG`
<TR>
<TD ALIGN=LEFT NOWRAP>
Linker (shared libs)
<TD ALIGN=LEFT NOWRAP>
`CGAL_SHARED_LINKER_FLAGS`
<TD ALIGN=LEFT NOWRAP>
`CGAL_SHARED_LINKER_FLAGS_RELEASE`
<TD ALIGN=LEFT NOWRAP>
`CGAL_SHARED_LINKER_FLAGS_DEBUG`
<TR>
<TD ALIGN=LEFT NOWRAP>
Linker (static libs)
<TD ALIGN=LEFT NOWRAP>
`CGAL_MODULE_LINKER_FLAGS`
<TD ALIGN=LEFT NOWRAP>
`CGAL_MODULE_LINKER_FLAGS_RELEASE`
<TD ALIGN=LEFT NOWRAP>
`CGAL_MODULE_LINKER_FLAGS_DEBUG`
<TR>
<TD ALIGN=LEFT NOWRAP>
Linker (programs)
<TD ALIGN=LEFT NOWRAP>
`CGAL_EXE_LINKER_FLAGS`
<TD ALIGN=LEFT NOWRAP>
`CGAL_EXE_LINKER_FLAGS_RELEASE`
<TD ALIGN=LEFT NOWRAP>
`CGAL_EXE_LINKER_FLAGS_DEBUG`
</TABLE>
</SMALL>
\subsection installation_misc Miscellaneous Variables
<SMALL>
<TABLE CELLSPACING=5 BORDER=2>
<TR>
<TD ALIGN=LEFT NOWRAP>
<B>Variable</B>
<TD ALIGN=LEFT NOWRAP>
<B>Description</B>
<TD ALIGN=LEFT NOWRAP>
<B>Type</B>
<TD ALIGN=LEFT NOWRAP>
<B>Default value</B>
<TR>
<TD ALIGN=LEFT NOWRAP>
`CMAKE_BUILD_TYPE`
<TD ALIGN=LEFT NOWRAP>
Indicates type of build. Possible values are 'Debug' or 'Release'
<TD ALIGN=LEFT NOWRAP>
CMake
<TD ALIGN=LEFT NOWRAP>
Release
<TR>
<TD ALIGN=LEFT NOWRAP>
`CMAKE_CXX_COMPILER`
<TD ALIGN=LEFT NOWRAP>
Full-path to the executable corresponding to the C++ compiler to use.
<TD ALIGN=LEFT NOWRAP>
CMake
<TD ALIGN=LEFT NOWRAP>
platform-dependent
<TR>
<TD ALIGN=LEFT NOWRAP>
`CXX`
<TD ALIGN=LEFT NOWRAP>
Idem
<TD ALIGN=LEFT NOWRAP>
Environment
<TD ALIGN=LEFT NOWRAP>
Idem
</TABLE>
</SMALL>
\subsection installation_variables_building Variables used only when building programs (such as demos or examples)
<SMALL>
<TABLE CELLSPACING=5 BORDER=2>
<TR>
<TD ALIGN=LEFT NOWRAP>
<B>Variable</B>
<TD ALIGN=LEFT NOWRAP>
<B>Description</B>
<TD ALIGN=LEFT NOWRAP>
<B>Type</B>
<TD ALIGN=LEFT NOWRAP>
<B>Default value</B>
<TR>
<TD ALIGN=LEFT NOWRAP>
`CGAL_DIR`
<TD ALIGN=LEFT NOWRAP>
Full-path to the binary directory where \cgal was configured
<TD ALIGN=LEFT NOWRAP>
Either CMake or Environment
<TD ALIGN=LEFT NOWRAP>
<I>none</I>
</TABLE>
</SMALL>
\subsection installation_variables_third_party Variables providing information about 3rd-party libraries
\anchor sec3partysoftwareconfig
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.
\subsection installation_boost Boost libraries
In most cases, if \sc{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 \sc{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 \sc{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 \sc{Boost} `.dll` to the
`PATH` environment variable.
<SMALL>
<TABLE CELLSPACING=5 BORDER=2>
<TR>
<TD ALIGN=LEFT NOWRAP>
<B>Variable</B>
<TD ALIGN=LEFT NOWRAP>
<B>Description</B>
<TD ALIGN=LEFT NOWRAP>
<B>Type</B>
<TR>
<TD ALIGN=LEFT NOWRAP>
`BOOST_ROOT`<A HREF="#Footnote_16"><SUP>16</SUP></A>
<TD ALIGN=LEFT NOWRAP>
Root directory of your \sc{Boost} installation
<TD ALIGN=LEFT NOWRAP>
Either CMake or Environment
<TR>
<TD ALIGN=LEFT NOWRAP>
`Boost_INCLUDE_DIR`
<TD ALIGN=LEFT NOWRAP>
Directory containing the `boost/version.hpp` file
<TD ALIGN=LEFT NOWRAP>
CMake
<TR>
<TD ALIGN=LEFT NOWRAP>
`BOOST_INCLUDEDIR`
<TD ALIGN=LEFT NOWRAP>
Idem
<TD ALIGN=LEFT NOWRAP>
Environment
<TR>
<TD ALIGN=LEFT NOWRAP>
`Boost_LIBRARY_DIRS`
<TD ALIGN=LEFT NOWRAP>
Directory containing the compiled \sc{Boost} libraries
<TD ALIGN=LEFT NOWRAP>
CMake
<TR>
<TD ALIGN=LEFT NOWRAP>
`BOOST_LIBRARYDIR`
<TD ALIGN=LEFT NOWRAP>
Idem
<TD ALIGN=LEFT NOWRAP>
Environment
<TR>
<TD ALIGN=LEFT NOWRAP>
`Boost_(xyz)_LIBRARY_RELEASE`
<TD ALIGN=LEFT NOWRAP>
Full pathname to a release build of the compiled 'xyz' \sc{Boost} library
<TD ALIGN=LEFT NOWRAP>
CMake
<TR>
<TD ALIGN=LEFT NOWRAP>
`Boost_(xyz)_LIBRARY_DEBUG`
<TD ALIGN=LEFT NOWRAP>
Full pathname to a debug build of the compiled 'xyz' \sc{Boost} library
<TD ALIGN=LEFT NOWRAP>
CMake
</TABLE>
</SMALL>
\subsection installation_gmp Gmp and Mpfr Libraries
Under Windows, auto-linking is used, so only the <I>directory</I>
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 \sc{Gmp} and \sc{Mpfr} so both need to be supported. If either of them is unavailable the
usage of \sc{Gmp} and of \sc{Mpfr} will be disabled.
<SMALL>
<TABLE CELLSPACING=5 BORDER=2>
<TR>
<TD ALIGN=LEFT NOWRAP>
<B>Variable</B>
<TD ALIGN=LEFT NOWRAP>
<B>Description</B>
<TD ALIGN=LEFT NOWRAP>
<B>Type</B>
<TR>
<TD ALIGN=LEFT NOWRAP>
`WITH_GMP`
<TD ALIGN=LEFT NOWRAP>
Indicates whether to search and use \sc{Gmp}/\sc{Mpfr} or not
<TD ALIGN=LEFT NOWRAP>
CMake
<TR>
<TD ALIGN=LEFT NOWRAP>
`GMP_DIR`
<TD ALIGN=LEFT NOWRAP>
Directory of \sc{Gmp} default installation
<TD ALIGN=LEFT NOWRAP>
Environment
<TR>
<TD ALIGN=LEFT NOWRAP>
`GMP_INCLUDE_DIR`
<TD ALIGN=LEFT NOWRAP>
Directory containing the `gmp.h` file
<TD ALIGN=LEFT NOWRAP>
CMake
<TR>
<TD ALIGN=LEFT NOWRAP>
`GMP_INC_DIR`
<TD ALIGN=LEFT NOWRAP>
Idem
<TD ALIGN=LEFT NOWRAP>
Environment
<TR>
<TD ALIGN=LEFT NOWRAP>
`GMP_LIBRARIES_DIR`
<TD ALIGN=LEFT NOWRAP>
Directory containing the compiled \sc{Gmp} library
<TD ALIGN=LEFT NOWRAP>
CMake
<TR>
<TD ALIGN=LEFT NOWRAP>
`GMP_LIB_DIR`
<TD ALIGN=LEFT NOWRAP>
Idem
<TD ALIGN=LEFT NOWRAP>
Environment
<TR>
<TD ALIGN=LEFT NOWRAP>
`GMP_LIBRARIES`
<TD ALIGN=LEFT NOWRAP>
Full pathname of the compiled \sc{Gmp} library
<TD ALIGN=LEFT NOWRAP>
CMake
<TR>
<TD ALIGN=LEFT NOWRAP>
`MPFR_INCLUDE_DIR`
<TD ALIGN=LEFT NOWRAP>
Directory containing the `mpfr.h` file
<TD ALIGN=LEFT NOWRAP>
CMake
<TR>
<TD ALIGN=LEFT NOWRAP>
`MPFR_INC_DIR`
<TD ALIGN=LEFT NOWRAP>
Idem
<TD ALIGN=LEFT NOWRAP>
Environment
<TR>
<TD ALIGN=LEFT NOWRAP>
`MPFR_LIBRARIES_DIR`
<TD ALIGN=LEFT NOWRAP>
Directory containing the compiled \sc{Mpfr} library
<TD ALIGN=LEFT NOWRAP>
CMake
<TR>
<TD ALIGN=LEFT NOWRAP>
`MPFR_LIB_DIR`
<TD ALIGN=LEFT NOWRAP>
Idem
<TD ALIGN=LEFT NOWRAP>
Environment
<TR>
<TD ALIGN=LEFT NOWRAP>
`MPFR_LIBRARIES`
<TD ALIGN=LEFT NOWRAP>
Full pathname of the compiled \sc{Mpfr} library
<TD ALIGN=LEFT NOWRAP>
CMake
</TABLE>
</SMALL>
Under Linux, the \sc{Gmpxx} is also searched for, and you may specify the following variables:
<SMALL>
<TABLE CELLSPACING=5 BORDER=2>
<TR>
<TD ALIGN=LEFT NOWRAP>
<B>Variable</B>
<TD ALIGN=LEFT NOWRAP>
<B>Description</B>
<TD ALIGN=LEFT NOWRAP>
<B>Type</B>
<TR>
<TD ALIGN=LEFT NOWRAP>
`GMPXX_DIR`
<TD ALIGN=LEFT NOWRAP>
Directory of \sc{gmpxx} default installation
<TD ALIGN=LEFT NOWRAP>
Environment
<TR>
<TD ALIGN=LEFT NOWRAP>
`GMPXX_INCLUDE_DIR`
<TD ALIGN=LEFT NOWRAP>
Directory containing the `gmpxx.h` file
<TD ALIGN=LEFT NOWRAP>
CMake
<TR>
<TD ALIGN=LEFT NOWRAP>
`GMPXX_LIBRARIES`
<TD ALIGN=LEFT NOWRAP>
Full pathname of the compiled \sc{Gmpxx} library
<TD ALIGN=LEFT NOWRAP>
CMake
</TABLE>
</SMALL>
\subsection installation_qt3 Qt3 Library
In most cases, if \sc{Qt}3 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 \sc{Qt}3 libraries.
<SMALL>
<TABLE CELLSPACING=5 BORDER=2>
<TR>
<TD ALIGN=LEFT NOWRAP>
<B>Variable</B>
<TD ALIGN=LEFT NOWRAP>
<B>Description</B>
<TD ALIGN=LEFT NOWRAP>
<B>Type</B>
<TR>
<TD ALIGN=LEFT NOWRAP>
`QTDIR`
<TD ALIGN=LEFT NOWRAP>
Root directory of the \sc{Qt}3 library
<TD ALIGN=LEFT NOWRAP>
Environment
<TR>
<TD ALIGN=LEFT NOWRAP>
`QT3_INCLUDE_DIR`
<TD ALIGN=LEFT NOWRAP>
Directory containing the `qt.h` file
<TD ALIGN=LEFT NOWRAP>
CMake
<TR>
<TD ALIGN=LEFT NOWRAP>
`QT3_QT_LIBRARY`
<TD ALIGN=LEFT NOWRAP>
Full pathname to the qt library of \sc{Qt}3
<TD ALIGN=LEFT NOWRAP>
CMake
<TR>
<TD ALIGN=LEFT NOWRAP>
`QT3_QTMAIN_LIBRARY`
<TD ALIGN=LEFT NOWRAP>
Full pathname to the qtmain library of \sc{Qt}3
<TD ALIGN=LEFT NOWRAP>
CMake
<TR>
<TD ALIGN=LEFT NOWRAP>
`QT3_QASSISTANTCLIENT_LIBRARY`
<TD ALIGN=LEFT NOWRAP>
Full pathname to the qassistantclient library of \sc{Qt}3
<TD ALIGN=LEFT NOWRAP>
CMake
<TR>
<TD ALIGN=LEFT NOWRAP>
`QT3_MOC_EXECUTABLE`
<TD ALIGN=LEFT NOWRAP>
Full pathname to the moc executable of \sc{Qt}3
<TD ALIGN=LEFT NOWRAP>
CMake
<TR>
<TD ALIGN=LEFT NOWRAP>
`QT3_UIC_EXECUTABLE`
<TD ALIGN=LEFT NOWRAP>
Full pathname to the uic executable of \sc{Qt}3
<TD ALIGN=LEFT NOWRAP>
CMake
</TABLE>
</SMALL>
\subsection installation_qt4 Qt4 Library
The CMake scripts that search for \sc{Qt}4 can use the introspection feature
of the tool `qmake` included in \sc{Qt}4 distributions. If \sc{Qt}4 is not
automatically found, it is sufficient to set the `PATH`
environment variable, so that \sc{Qt}4 `qmake` tool is in the path, and
before \sc{Qt}3 `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.
<SMALL>
<TABLE CELLSPACING=5 BORDER=2>
<TR>
<TD ALIGN=LEFT NOWRAP>
<B>Variable</B>
<TD ALIGN=LEFT NOWRAP>
<B>Description</B>
<TD ALIGN=LEFT NOWRAP>
<B>Type</B>
<TR>
<TD ALIGN=LEFT NOWRAP>
`QT_INCLUDE_DIR`
<TD ALIGN=LEFT NOWRAP>
Directory containing the `QtCore/qglobal.h` file
<TD ALIGN=LEFT NOWRAP>
CMake
<TR>
<TD ALIGN=LEFT NOWRAP>
`QT_LIBRARY_DIR`
<TD ALIGN=LEFT NOWRAP>
Directory containing the compiled \sc{Qt}4 libraries
<TD ALIGN=LEFT NOWRAP>
CMake
<TR>
<TD ALIGN=LEFT NOWRAP>
`QT_(xyz)_LIBRARY`
<TD ALIGN=LEFT NOWRAP>
Full pathname to the compiled 'xyz' \sc{Qt}4 library<A HREF="#Footnote_17"><SUP>17</SUP></A>
<TD ALIGN=LEFT NOWRAP>
CMake
<TR>
<TD ALIGN=LEFT NOWRAP>
`QT_QMAKE_EXECUTABLE`
<TD ALIGN=LEFT NOWRAP>
Full pathname to the qmake executable of \sc{Qt}4
<TD ALIGN=LEFT NOWRAP>
CMake
<TR>
<TD ALIGN=LEFT NOWRAP>
`QT_MOC_EXECUTABLE`
<TD ALIGN=LEFT NOWRAP>
Full pathname to the moc executable of \sc{Qt}4
<TD ALIGN=LEFT NOWRAP>
CMake
<TR>
<TD ALIGN=LEFT NOWRAP>
`QT_UIC_EXECUTABLE`
<TD ALIGN=LEFT NOWRAP>
Full pathname to the uic executable of \sc{Qt}4
<TD ALIGN=LEFT NOWRAP>
CMake
</TABLE>
</SMALL>
\subsection installation_leda 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.
<SMALL>
<TABLE CELLSPACING=5 BORDER=2>
<TR>
<TD ALIGN=LEFT NOWRAP>
<B>Variable</B>
<TD ALIGN=LEFT NOWRAP>
<B>Description</B>
<TD ALIGN=LEFT NOWRAP>
<B>Type</B>
<TR>
<TD ALIGN=LEFT NOWRAP>
`WITH_LEDA`
<TD ALIGN=LEFT NOWRAP>
Indicates whether to search and use \leda or not
<TD ALIGN=LEFT NOWRAP>
CMake
<TR>
<TD ALIGN=LEFT NOWRAP>
`LEDA_DIR`
<TD ALIGN=LEFT NOWRAP>
Directory of \sc{LEDA} default installation
<TD ALIGN=LEFT NOWRAP>
Environment
<TR>
<TD ALIGN=LEFT NOWRAP>
`LEDA_INCLUDE_DIR`
<TD ALIGN=LEFT NOWRAP>
Directory containing the file `LEDA/system/basic.h`
<TD ALIGN=LEFT NOWRAP>
CMake
<TR>
<TD ALIGN=LEFT NOWRAP>
`LEDA_LIBRARIES`
<TD ALIGN=LEFT NOWRAP>
Directory containing the compiled \leda libraries
<TD ALIGN=LEFT NOWRAP>
CMake
<TR>
<TD ALIGN=LEFT NOWRAP>
`LEDA_INC_DIR`
<TD ALIGN=LEFT NOWRAP>
Directory containing the file `LEDA/system/basic.h`
<TD ALIGN=LEFT NOWRAP>
Environment
<TR>
<TD ALIGN=LEFT NOWRAP>
`LEDA_LIB_DIR`
<TD ALIGN=LEFT NOWRAP>
Directory containing the compiled \leda libraries
<TD ALIGN=LEFT NOWRAP>
Environment
<TR>
<TD ALIGN=LEFT NOWRAP>
`LEDA_LIBRARY_RELEASE`
<TD ALIGN=LEFT NOWRAP>
Full pathname to a release build of the \leda library
<TD ALIGN=LEFT NOWRAP>
Either CMake
<TR>
<TD ALIGN=LEFT NOWRAP>
`LEDA_LIBRARY_DEBUG`
<TD ALIGN=LEFT NOWRAP>
Full pathname to a debug build of the \leda library
<TD ALIGN=LEFT NOWRAP>
Either CMake
<TR>
<TD ALIGN=LEFT NOWRAP>
`LEDA_DEFINITIONS`
<TD ALIGN=LEFT NOWRAP>
Preprocessor definitions
<TD ALIGN=LEFT NOWRAP>
Either CMake
<TR>
<TD ALIGN=LEFT NOWRAP>
`LEDA_CXX_FLAGS`
<TD ALIGN=LEFT NOWRAP>
Compiler flags
<TD ALIGN=LEFT NOWRAP>
Either CMake
<TR>
<TD ALIGN=LEFT NOWRAP>
`LEDA_LINKER_FLAGS`
<TD ALIGN=LEFT NOWRAP>
Linker flags
<TD ALIGN=LEFT NOWRAP>
Either CMake
</TABLE>
</SMALL>
\subsection installation_mpfi Mpfi Library
\cgal provides a number type based on this library, but the \cgal library
itself does not depend on \sc{Mpfi}. This means that this library must be
configured when compiling an application that uses the above number type.
When \sc{Mpfi} files are not on the standard path, the locations of the headers
and library files must be specified by using environment variables.
<SMALL>
<TABLE CELLSPACING=5 BORDER=2>
<TR>
<TD ALIGN=LEFT NOWRAP>
<B>Variable</B>
<TD ALIGN=LEFT NOWRAP>
<B>Description</B>
<TD ALIGN=LEFT NOWRAP>
<B>Type</B>
<TR>
<TD ALIGN=LEFT NOWRAP>
`MPFI_DIR`
<TD ALIGN=LEFT NOWRAP>
Directory of \sc{MPFI} default installation
<TD ALIGN=LEFT NOWRAP>
Environment
<TR>
<TD ALIGN=LEFT NOWRAP>
`MPFI_INCLUDE_DIR`
<TD ALIGN=LEFT NOWRAP>
Directory containing the `mpfi.h` file
<TD ALIGN=LEFT NOWRAP>
CMake
<TR>
<TD ALIGN=LEFT NOWRAP>
`MPFI_INC_DIR`
<TD ALIGN=LEFT NOWRAP>
Idem
<TD ALIGN=LEFT NOWRAP>
Environment
<TR>
<TD ALIGN=LEFT NOWRAP>
`MPFI_LIBRARIES_DIR`
<TD ALIGN=LEFT NOWRAP>
Directory containing the compiled \sc{Mpfi} library
<TD ALIGN=LEFT NOWRAP>
CMake
<TR>
<TD ALIGN=LEFT NOWRAP>
`MPFI_LIB_DIR`
<TD ALIGN=LEFT NOWRAP>
Idem
<TD ALIGN=LEFT NOWRAP>
Environment
<TR>
<TD ALIGN=LEFT NOWRAP>
`MPFI_LIBRARIES`
<TD ALIGN=LEFT NOWRAP>
Full pathname of the compiled \sc{Mpfi} library
<TD ALIGN=LEFT NOWRAP>
CMake
</TABLE>
</SMALL>
\subsection installation_rs 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 \sc{Gmp} 4.2 or later and \sc{Mpfi} 1.3.4 or later. The variables
related to the latter library may also need to be defined.
<SMALL>
<TABLE CELLSPACING=5 BORDER=2>
<TR>
<TD ALIGN=LEFT NOWRAP>
<B>Variable</B>
<TD ALIGN=LEFT NOWRAP>
<B>Description</B>
<TD ALIGN=LEFT NOWRAP>
<B>Type</B>
<TR>
<TD ALIGN=LEFT NOWRAP>
`RS_DIR`
<TD ALIGN=LEFT NOWRAP>
Directory of \sc{RS} default installation
<TD ALIGN=LEFT NOWRAP>
Environment
<TR>
<TD ALIGN=LEFT NOWRAP>
`RS_INCLUDE_DIR`
<TD ALIGN=LEFT NOWRAP>
Directory containing the `rs_exports.h` file
<TD ALIGN=LEFT NOWRAP>
CMake
<TR>
<TD ALIGN=LEFT NOWRAP>
`RS_INC_DIR`
<TD ALIGN=LEFT NOWRAP>
Idem
<TD ALIGN=LEFT NOWRAP>
Environment
<TR>
<TD ALIGN=LEFT NOWRAP>
`RS_LIBRARIES_DIR`
<TD ALIGN=LEFT NOWRAP>
Directory containing the compiled Rs library
<TD ALIGN=LEFT NOWRAP>
CMake
<TR>
<TD ALIGN=LEFT NOWRAP>
`RS_LIB_DIR`
<TD ALIGN=LEFT NOWRAP>
Idem
<TD ALIGN=LEFT NOWRAP>
Environment
<TR>
<TD ALIGN=LEFT NOWRAP>
`RS_LIBRARIES`
<TD ALIGN=LEFT NOWRAP>
Full pathname of the compiled Rs library
<TD ALIGN=LEFT NOWRAP>
CMake
</TABLE>
</SMALL>
Similar variables exist for Rs3.
<SMALL>
<TABLE CELLSPACING=5 BORDER=2>
<TR>
<TD ALIGN=LEFT NOWRAP>
<B>Variable</B>
<TD ALIGN=LEFT NOWRAP>
<B>Description</B>
<TD ALIGN=LEFT NOWRAP>
<B>Type</B>
<TR>
<TD ALIGN=LEFT NOWRAP>
`RS3_DIR`
<TD ALIGN=LEFT NOWRAP>
Directory of \sc{RS3} default installation
<TD ALIGN=LEFT NOWRAP>
Environment
<TR>
<TD ALIGN=LEFT NOWRAP>
`RS3_INCLUDE_DIR`
<TD ALIGN=LEFT NOWRAP>
Directory containing the file `rs3_fncts.h` file
<TD ALIGN=LEFT NOWRAP>
CMake
<TR>
<TD ALIGN=LEFT NOWRAP>
`RS3_INC_DIR`
<TD ALIGN=LEFT NOWRAP>
Idem
<TD ALIGN=LEFT NOWRAP>
Environment
<TR>
<TD ALIGN=LEFT NOWRAP>
`RS3_LIBRARIES_DIR`
<TD ALIGN=LEFT NOWRAP>
Directory containing the compiled Rs3 library
<TD ALIGN=LEFT NOWRAP>
CMake
<TR>
<TD ALIGN=LEFT NOWRAP>
`RS3_LIB_DIR`
<TD ALIGN=LEFT NOWRAP>
Idem
<TD ALIGN=LEFT NOWRAP>
Environment
<TR>
<TD ALIGN=LEFT NOWRAP>
`RS3_LIBRARIES`
<TD ALIGN=LEFT NOWRAP>
Full pathname of the compiled Rs3 library
<TD ALIGN=LEFT NOWRAP>
CMake
</TABLE>
</SMALL>
\subsection installation_ntl Ntl Library
Some polynomial computations in \cgal's algebraic kernel
are speed up when \sc{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 \sc{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.
<SMALL>
<TABLE CELLSPACING=5 BORDER=2>
<TR>
<TD ALIGN=LEFT NOWRAP>
<B>Variable</B>
<TD ALIGN=LEFT NOWRAP>
<B>Description</B>
<TD ALIGN=LEFT NOWRAP>
<B>Type</B>
<TR>
<TD ALIGN=LEFT NOWRAP>
`NTL_DIR`
<TD ALIGN=LEFT NOWRAP>
Directory of \sc{NTL} default installation
<TD ALIGN=LEFT NOWRAP>
Environment
<TR>
<TD ALIGN=LEFT NOWRAP>
`NTL_INCLUDE_DIR`
<TD ALIGN=LEFT NOWRAP>
Directory containing the `NTL/ZZX.h` file
<TD ALIGN=LEFT NOWRAP>
CMake
<TR>
<TD ALIGN=LEFT NOWRAP>
`NTL_INC_DIR`
<TD ALIGN=LEFT NOWRAP>
Idem
<TD ALIGN=LEFT NOWRAP>
Environment
<TR>
<TD ALIGN=LEFT NOWRAP>
`NTL_LIBRARIES_DIR`
<TD ALIGN=LEFT NOWRAP>
Directory containing the compiled \sc{Ntl} library
<TD ALIGN=LEFT NOWRAP>
CMake
<TR>
<TD ALIGN=LEFT NOWRAP>
`NTL_LIB_DIR`
<TD ALIGN=LEFT NOWRAP>
Idem
<TD ALIGN=LEFT NOWRAP>
Environment
<TR>
<TD ALIGN=LEFT NOWRAP>
`NTL_LIBRARIES`
<TD ALIGN=LEFT NOWRAP>
Full pathname of the compiled \sc{Ntl} library
<TD ALIGN=LEFT NOWRAP>
CMake
</TABLE>
</SMALL>
\subsection installation_eigen Eigen Library
\sc{Eigen} is a header-only template library.
Only the <I>directory</I> containing the header files of \sc{Eigen} 3.1 (or greater) is needed.
<SMALL>
<TABLE CELLSPACING=5 BORDER=2>
<TR>
<TD ALIGN=LEFT NOWRAP>
<B>Variable</B>
<TD ALIGN=LEFT NOWRAP>
<B>Description</B>
<TD ALIGN=LEFT NOWRAP>
<B>Type</B>
<TR>
<TD ALIGN=LEFT NOWRAP>
`EIGEN3_DIR`
<TD ALIGN=LEFT NOWRAP>
Directory of \sc{EIGEN} default installation
<TD ALIGN=LEFT NOWRAP>
Environment
<TR>
<TD ALIGN=LEFT NOWRAP>
`EIGEN3_INCLUDE_DIR`
<TD ALIGN=LEFT NOWRAP>
Directory containing the file `signature_of_eigen3_matrix_library`
<TD ALIGN=LEFT NOWRAP>
CMake
<TR>
<TD ALIGN=LEFT NOWRAP>
`EIGEN3_INC_DIR`
<TD ALIGN=LEFT NOWRAP>
Idem
<TD ALIGN=LEFT NOWRAP>
Environment
</TABLE>
</SMALL>
\subsection installation_qgl 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
<SMALL>
<TABLE CELLSPACING=5 BORDER=2>
<TR>
<TD ALIGN=LEFT NOWRAP>
<B>Variable</B>
<TD ALIGN=LEFT NOWRAP>
<B>Description</B>
<TD ALIGN=LEFT NOWRAP>
<B>Type</B>
<TR>
<TD ALIGN=LEFT NOWRAP>
`QGLVIEWERROOT`
<TD ALIGN=LEFT NOWRAP>
Root directory of the QGLViewer library
<TD ALIGN=LEFT NOWRAP>
Environment
<TR>
<TD ALIGN=LEFT NOWRAP>
`QGLVIEWER_INCLUDE_DIR`
<TD ALIGN=LEFT NOWRAP>
Directory containing the `QGLViewer/qglviewer.h` file
<TD ALIGN=LEFT NOWRAP>
CMake
<TR>
<TD ALIGN=LEFT NOWRAP>
`QGLVIEWER_LIBRARY_RELEASE`
<TD ALIGN=LEFT NOWRAP>
Full pathname to a release build of the QGLViewer library
<TD ALIGN=LEFT NOWRAP>
CMake
<TR>
<TD ALIGN=LEFT NOWRAP>
`QGLVIEWER_LIBRARY_DEBUG`
<TD ALIGN=LEFT NOWRAP>
Full pathname to a debug build of the QGLViewer library
<TD ALIGN=LEFT NOWRAP>
CMake
</TABLE>
</SMALL>
\subsection installation_esbtl ESBTL Library
One skin surface example requires the ESBTL library in order to read \sc{Pdb} files.
If ESBTL is not automatically found, setting the `ESBTL_INC_DIR`
environment variable is sufficient.
<SMALL>
<TABLE CELLSPACING=5 BORDER=2>
<TR>
<TD ALIGN=LEFT NOWRAP>
<B>Variable</B>
<TD ALIGN=LEFT NOWRAP>
<B>Description</B>
<TD ALIGN=LEFT NOWRAP>
<B>Type</B>
<TR>
<TD ALIGN=LEFT NOWRAP>
`ESBTL_DIR`
<TD ALIGN=LEFT NOWRAP>
Directory of \sc{ESBTL} default installation
<TD ALIGN=LEFT NOWRAP>
Environment
<TR>
<TD ALIGN=LEFT NOWRAP>
`ESBTL_INC_DIR`
<TD ALIGN=LEFT NOWRAP>
Directory containing the `ESBTL/default.h` file
<TD ALIGN=LEFT NOWRAP>
Environment
<TR>
<TD ALIGN=LEFT NOWRAP>
`ESBTL_INCLUDE_DIR`
<TD ALIGN=LEFT NOWRAP>
Directory containing the `ESBTL/default.h` file
<TD ALIGN=LEFT NOWRAP>
CMake
</TABLE>
</SMALL>
\section installation_compiler_workarounds 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 <TT><CGAL/compiler_config.h></TT>
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-x.y/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.
\section seccompileroptimisations Compiler Optimizations
By default CMake generates makefiles for Release mode, with
optimization flags switched on, and vcproj files for Release
and Debug modes.
*/
Reference in New Issue View Git Blame Copy Permalink