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

pass on the doc

This commit is contained in:
Sébastien Loriot 2019-10-17 15:02:47 +02:00
parent 76cc4a6863
commit bbfb23181e
9 changed files with 404 additions and 131 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

4
Documentation/doc/Documentation/Getting_started.txt
View File

@ -1,9 +1,9 @@
/*!
\page general_intro Getting Started with %CGAL
- \subpage usage describes the few steps required to build a program using \cgal.
- \subpage usage describes how to get \cgal and the few steps required to build a program using \cgal.
- \subpage thirdparty lists the third party libraries on which \cgal depends, or for which \cgal provides interfaces.
- \subpage thirdparty lists required and optional third party libraries.
- \subpage manual gives an idea of where you should look for documentation.

4
Documentation/doc/Documentation/Preliminaries.txt
View File

@ -3,10 +3,6 @@
\page preliminaries General Information
\cgalAutoToc
\cgalModifBegin
This page is bad...
\cgalModifEnd
The chapter explains some basic features of \cgal such as thread safety, code deprecation,
checking of pre- and postconditions and altering the failure behavior, and how to control inlining.

347
Documentation/doc/Documentation/Third_party.txt
View File

@ -37,7 +37,7 @@ 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 most of \cgal, and must therefore be found during the configuration of \cgal.
The page \ref configurationvariables lists CMake and environment variables which can be used to specify
The section \ref configurationvariables lists CMake and environment variables which can be used to specify
the location of third-party software during configuration.
\subsection thirdpartystl Standard Template Library (STL)
@ -97,7 +97,7 @@ certain optional libraries might be 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 where specialized libraries can be faster than the default
version shipped with \cgal.
The page \ref configurationvariables lists CMake and environment variables which can be used to specify
The section \ref configurationvariables lists CMake and environment variables which can be used to specify
the location of third-party software during configuration.
\subsection thirdpartyQt Qt5
@ -280,4 +280,347 @@ In \cgal, \sc{SCIP} provides an optional linear integer program solver in the \r
The \sc{SCIP} web site is <A HREF="http://scip.zib.de/">`http://scip.zib.de/`</A>.
\section configurationvariables 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 enable the compilation of all examples and demos
at the same time. Their values can be ON or OFF. New corresponding targets will be
created, the compilation will be triggered by calling `make examples` and `make demos`.
To build a particular subset of examples or demos, from your build directory go
to the subdirectory `demo/PKG` or `example/PKG` and simply call make from there.
| Variable | %Default Value |
| :------- | :--------------- |
| `WITH_examples` | OFF |
| `WITH_demos` | OFF |
\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.
| 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`|
\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.
| 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` |
\subsection installation_misc Miscellaneous Variables
Note that the default build type is <b>`Debug`</b>, which should only be used to debug
and will serverly limit performances.
| Variable | Description | Type | %Default Value |
| :- | :- | :- | :- |
| `CMAKE_BUILD_TYPE` | Indicates type of build. Possible values are 'Debug' or 'Release' | CMake | |
| `CMAKE_INSTALL_PREFIX`| Installation directory path | CMake | Debug |
| `CMAKE_C_COMPILER` | Full-path to the executable corresponding to the C compiler to use. | CMake | platform-dependent |
| `CMAKE_CXX_COMPILER` | Full-path to the executable corresponding to the C++ compiler to use. | CMake | platform-dependent |
| `CXX` | Idem | Environment | Idem |
| `BUILD_SHARED_LIBS` | Whether to build shared or static libraries. | CMake | TRUE |
\subsection installation_variables_building 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 |
\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.
| Variable | Description | Type |
| :- | :- | :- |
| `BOOST_ROOT`\cgalFootnote{The environment variable can be spelled either `BOOST_ROOT` or `BOOSTROOT`} | Root directory of your \sc{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 \sc{Boost} libraries | CMake |
| `BOOST_LIBRARYDIR` | Idem | Environment |
| `Boost_(xyz)_LIBRARY_RELEASE` | Full pathname to a release build of the compiled 'xyz' \sc{Boost} library | CMake |
| `Boost_(xyz)_LIBRARY_DEBUG` | Full pathname to a debug build of the compiled 'xyz' \sc{Boost} library | CMake |
\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.
| Variable | Description | Type |
| :- | :- | :- |
| `CGAL_DISABLE_GMP` | Indicates whether to search and use \sc{Gmp}/\sc{Mpfr} or not | CMake |
| `GMP_DIR` | Directory of \sc{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 \sc{Gmp} library | CMake |
| `GMP_LIB_DIR` | Idem | Environment |
| `GMP_LIBRARIES` | Full pathname of the compiled \sc{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 \sc{Mpfr} library | CMake |
| `MPFR_LIB_DIR` | Idem | Environment |
| `MPFR_LIBRARIES` | Full pathname of the compiled \sc{Mpfr} library | CMake |
Under Linux, the \sc{Gmpxx} is also searched for, and you may specify the following variables:
| Variable | Description | Type |
| :- | :- | :- |
| `GMPXX_DIR` | Directory of \sc{gmpxx} default installation | Environment |
| `GMPXX_INCLUDE_DIR` | Directory containing the `gmpxx.h` file | CMake |
| `GMPXX_LIBRARIES` | Full pathname of the compiled \sc{Gmpxx} library | CMake |
\subsection installation_qt5 Qt5 Library
You must set the cmake or environment variable `Qt5_DIR` to point to the path
to the directory containing the file `Qt5Config.cmake` created by your \sc{Qt}5 installation. If you are
using the open source edition it should be `<path>/qt-everywhere-opensource-src-<version>/qtbase/lib/cmake/Qt5`.
\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.
| Variable | Description | Type |
| :- | :- | :- |
| `WITH_LEDA` | Indicates whether to search and use \leda or not | CMake |
| `LEDA_DIR` | Directory of \sc{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 |
\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.
| Variable | Description | Type |
| :- | :- | :- |
| `MPFI_DIR` |Directory of \sc{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 \sc{Mpfi} library | CMake |
| `MPFI_LIB_DIR` | Idem | Environment |
| `MPFI_LIBRARIES` | Full pathname of the compiled \sc{Mpfi} library | CMake |
\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.
| Variable | Description | Type |
| :- | :- | :- |
| `RS_DIR` | Directory of \sc{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 \sc{Rs} library | CMake |
| `RS_LIB_DIR` | Idem | Environment |
| `RS_LIBRARIES` | Full pathname of the compiled \sc{Rs} library | CMake |
Similar variables exist for \sc{Rs3}.
| Variable | Description | Type |
| :- | :- | :-
| `RS3_DIR` | Directory of \sc{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 \sc{Rs3} library | CMake |
| `RS3_LIB_DIR` | Idem | Environment |
| `RS3_LIBRARIES` | Full pathname of the compiled \sc{Rs3} library | CMake |
\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.
| Variable | Description | Type |
| :- | :- | :- |
| `NTL_DIR` | Directory of \sc{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 \sc{Ntl} library | CMake |
| `NTL_LIB_DIR` | Idem | Environment |
| `NTL_LIBRARIES` | Full pathname of the compiled \sc{Ntl} library | CMake |
\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.
| Variable | Description | Type |
| :- | :- | :- |
| `EIGEN3_INCLUDE_DIR` | Directory containing the file `signature_of_eigen3_matrix_library` | CMake |
| `EIGEN3_INC_DIR` | Idem | Environment |
\subsection installation_esbtl ESBTL Library
One skin surface example requires the \sc{Esbtl} library in order to read \sc{Pdb} files.
If \sc{Esbtl} is not automatically found, setting the `ESBTL_INC_DIR`
environment variable is sufficient.
| Variable | Description | Type |
| :- | :- | :- |
| `ESBTL_DIR` | Directory of \sc{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 |
\subsection installation_tbb TBB Library
If \sc{Tbb} is not automatically found, the user must set the `TBB_ROOT`
environment variable. The environment variable `TBB_ARCH_PLATFORM=<arch>/<compiler>` must be set.
`<arch>` is `ia32` or `intel64`. `<compiler>` describes the Linux kernel, gcc version or Visual Studio version
used. It should be set to what is used in `$TBB_ROOT/lib/<arch>`.
For windows users, the folder `TBB_ROOT/bin/<arch>/<compiler>` should be added to the `PATH` variable.
Note that the variables in the table below are being used.
| Variable | Description | Type |
| :- | :- | :- |
| `TBB_ROOT` | Directory of \sc{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 |
\subsection 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-\cgalReleaseNumber``/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.
*/

72
Documentation/doc/Documentation/Usage.txt
View File

@ -6,14 +6,16 @@ Since \cgal version 5.0, \cgal is header-only be default, which means
that there is <b>no need to build or install \cgal before it can be used</b>.
However, some dependencies of \cgal might still need to be installed.
\section usage_introduction Quick Start
\section usage_introduction Quick Start: Compiling a Program using CGAL
Ideally, compiling an example shipped with \cgal is as simple as:
Given that you have extracted the \cgal source archive in `$HOME`, compiling an example shipped with \cgal is as simple as:
cd examples/Triangulation_2 # go to an example directory
cd $HOME/CGAL-\cgalReleaseNumber/examples/Triangulation_2 # go to an example directory
cmake -DCGAL_DIR=$HOME/CGAL-\cgalReleaseNumber -DCMAKE_BUILD_TYPE=Release . # configure the examples
make # build the examples
On Windows, instead of calling `make` simply double-click on the generated solution (`.sln`) to open Visual C++.
Compiling your own program is similar:
cd /path/to/your/program
@ -23,14 +25,10 @@ Compiling your own program is similar:
The script `cgal_create_CMakeLists` and its options are detailed in Section \ref devman_create_cgal_CMakeLists.
\cgalModifBegin
Something about Windows?
\cgalModifEnd
In a less ideal world, you might have to install some required tools and third-party libraries.
This is what this page is about.
\section secprerequisites Prerequisites
\section secprerequisites Prerequisites
Using \cgal requires a few core components to be previously installed:
<ul>
@ -45,6 +43,41 @@ or to build your own project using \cgal, see Section \ref secoptional3rdpartyso
\section secgettingcgal Downloading CGAL
\subsection secusingpkgman Using a Package Manager
On most common operating systems, package managers offer \cgal and its essential third party dependencies.
On macOS we recommend to use of <a href="https://brew.sh/">Homebrew</a> in the following way:
brew install cgal
If not automatically found, the `CGAL_DIR` to provide to cmake when configuring a program using \cgal should be something like `/usr/local/Cellar/cgal/4.14.1/lib/cmake/CGAL`.
On Linux distributions like Debian/Ubuntu/Mint, use `apt-get` in the following way:
sudo apt-get install libcgal-dev
If not automatically found, the `CGAL_DIR` to provide to cmake when configuring a program using \cgal should be something like `/usr/lib/x86_64-linux-gnu/cmake/CGAL`.
On Windows, we recommand to use <a href="https://github.com/microsoft/vcpkg">vcpkg</a> in the following way:
vcpkg install cgal
If not automatically found, the `CGAL_DIR` to provide to cmake when configuring a program using \cgal should be something like `VCPK_DIR/packages/cgal_x64-windows/lib/cgal`
For other distributions or package manager, please consult your respective documentation.
\subsection sseccgalwindows Using CGAL installer on Windows
You can download and run `CGAL-\cgalReleaseNumber``-Setup.exe` from https://www.cgal.org/download/windows.html.
It is a self extracting executable that installs the \cgal source, and that allows you
to select and download some precompiled third party libraries. However, you will need to compile
the library using your favorite compiler.
A <a href="https://www.cgal.org/download/windows.html">tutorial</a> is provided on how to proceed with Microsoft Visual Studio.
\subsection secusingwebsite From CGAL website
You can obtain the \cgal library from
<A HREF="https://www.cgal.org/download.html">https://www.cgal.org/download.html</A>.
@ -95,29 +128,6 @@ Note that even though \cgal can be used as a header-only library, not all its de
are header-only. The libraries \sc{Gmp} and \sc{Mpfr}, for example, are not
header-only. As such, these dependencies must be built or installed independently.
\subsection subsection_headeronly_pbonwindows Potential Issue on Windows
\cgalModifBegin
(RE)MOVE THAT?
\cgalModifEnd
A potential issue when using \cgal in header-only mode on a Windows operating system can arise
when compiling a program using several modules (executable programs or dynamic-link libraries DLL).
If two different modules use the same static variable, this variable is defined independently
in each of these modules. If one module modifies the value of this variable, it will not be modified
in the other module, which could induce an unexpected behavior. In \cgal, this concerns only
a few specific variables: the <A HREF="https://doc.cgal.org/latest/Generator/classCGAL_1_1Random.html">default random</A>,
the <A HREF="https://doc.cgal.org/latest/STL_Extension/group__PkgSTLExtensionAssertions.html">failure behavior</A>,
`CGAL::IO::Mode`. One example is the following: if you change the default random in one DLL, then
if you use the default random in another DLL, you will not obtain the modified default random but the original one.
\subsection usage_installingcgal Building and Installing CGAL
Although using the header-only mode makes building and installing \cgal obsolete, it is still possible
to configure, build, and install \cgal. Head over to \ref installation for more information. It is
however advised by the \cgal project to use the much simpler header-only mode, and the present page
assumes that this configuration is being used.
\section usage_configuring Configuring your Program
Before building anything using \cgal you have to choose the compiler/linker, set compiler

9
Documentation/doc/Documentation/main.txt
View File

@ -25,14 +25,6 @@ the Boost Graph Library.
Getting Started
===============
\cgalModifBegin
remove?
In the distribution of the library, you will find the directories *demo* and *examples*.
They contain subdirectories for the \cgal packages.
The demos use third-party libraries for the graphical user interface.
The examples do not have this dependency and most examples are referred to in the user manual.
\cgalModifEnd
Head over to the page \ref general_intro, which will guide your first steps with \cgal.
License
@ -56,7 +48,6 @@ For releases X.Y, with 3.1 <= X.Y <= 4.1 visit
\endhtmlonly
\subpage general_intro
\subpage advanced
\subpage tutorials
\subpage packages
\subpage dev_manual

55
INSTALL.md
View File

@ -1,9 +1,8 @@
NOTICE
======
Since Version 5.0, CGAL is now header-only by default, meaning that it is no longer mandatory
to build (and install) CGAL and its libraries. Usage of CGAL as a header-only library should
thus simply amount to:
Since Version 5.0, CGAL is a header-only library it is not needed
to build and install it. Usage of CGAL should thus simply amount to:
``` {.bash}
git clone https://github.com/CGAL/cgal.git /path/to/cgal.git
@ -16,38 +15,17 @@ make
in the case of the building of an example in debug mode.
More information on dependencies, configuration flags, and useful scripts to build programs that are not shipped
with CGAL can be found on header-only usage at https://doc.cgal.org/latest/Manual/general_intro.html,
noting that this page describes the setting of CGAL as a sources release and, as such,
For more information head over to the [CGAL manual](https://doc.cgal.org/latest/Manual/general_intro.html).
Note that this page describes the setting of CGAL as a sources release and, as such,
files are organized in a slightly different way, see the [Layout of the CGAL Git Repository](README.md).
BRANCH BUILD OF CGAL
====================
Although not recommended, it is still possible to build (and install) CGAL.
The cmake script at the root of the repository is the one to use to
build the CGAL library from a branch. It will collect the list of packages
of the branch and will append their include folder to the include path.
This is main noticeable difference with a build using a regular *flat* release.
Here is an example of how to build the library in Release:
``` {.bash}
git clone https://github.com/CGAL/cgal.git /path/to/cgal.git
cd /path/to/cgal.git
mkdir -p build/release
cd build/release
cmake -DCMAKE_BUILD_TYPE=Release ../..
make
```
Note that *no installation is required* to use that version of CGAL once it has been compiled.
Building a Program Using CGAL
=============================
To compile a program using CGAL, simply set `CGAL_DIR` to the location
of where you have built the library (environment or cmake variable).
of the directory containing `CGALConfig.cmake` (for example the root
of the extracted source archive or the root of a git checkout).
Here is an example of how to build in debug the examples from the 3D Triangulations package:
@ -55,7 +33,7 @@ Here is an example of how to build in debug the examples from the 3D Triangulati
cd /path/to/cgal.git/Triangulation_3/examples/Triangulation_3
mkdir -p build/debug
cd build/debug
cmake -DCGAL_DIR:PATH=/path/to/cgal.git/build/debug ../..
cmake -DCGAL_DIR:PATH=/path/to/cgal.git ../..
make
```
@ -70,23 +48,8 @@ Here is an example for the examples of the 2D Triangulation package:
cd /path/to/cgal.git/Triangulation_2/examples/Triangulation_2
mkdir -p build/debug
cd build/debug
cmake -DCGAL_DIR:PATH=/path/to/cgal.git/build/debug ../..
cmake -DCGAL_DIR:PATH=/path/to/cgal.git ../..
make
```
More information on building and installing CGAL is available in the CGAL manual,
at https://doc.cgal.org/latest/Manual/installation.html, noting that this page describes the setting
of CGAL as a sources release and, as such, files are organized in a slightly different way,
see the [Layout of the CGAL Git Repository](README.md).
Note If You Switch Between Branches
===================================
A build may be outdated after an include/dir has been deleted,
switched or even updated. This might lead to compile problems (link
with outdated version). Thus, it is recommended to build CGAL after
each update, switch, merge of a branch (in particular if directories
have been added/deleted, or cpp files have been added, deleted or
altered).
For more information head over to the [CGAL manual](https://doc.cgal.org/latest/Manual/general_intro.html).

15
Installation/INSTALL.md
View File

@ -1,8 +1,7 @@
NOTICE
======
Since Version 5.0, CGAL is now header-only by default, meaning that it is no longer mandatory
to build (and install) CGAL and its libraries. Usage of CGAL as a header-only library
Since Version 5.0, CGAL is now header-only by default, meaning that you do not need to build and install CGAL. Usage of CGAL as a header-only library
simply amounts to, for example:
``` {.bash}
@ -13,14 +12,4 @@ cmake -DCMAKE_BUILD_TYPE=Debug -DCGAL_DIR=/path/to/cgal
make
```
More information on header-only dependencies, configuration flags, and useful scripts to build programs
that are not shipped with CGAL is available in this distribution in the file ./doc_html/index.html
("Getting Started with CGAL"), or on the CGAL website at https://doc.cgal.org/latest/Manual/general_intro.html
BUILDING AND INSTALLING CGAL
============================
Although not recommended, it is still possible to build and install CGAL. More information on
building and installing CGAL is available in this distribution in the file ./doc_html/index.html
("Advanced" > "Installation"), or on the CGAL website at https://doc.cgal.org/latest/Manual/installation.html
For more information head over to the [CGAL manual](https://doc.cgal.org/latest/Manual/general_intro.html).

10
Installation/doc_html/index.html
View File

@ -25,13 +25,9 @@ in the form of a C++ library.
</p>
<h3>Manuals</h3>
<ul>
<li><a href ="Manual/index.html">CGAL Manual - Table of Contents</a>
<li><a href ="Manual/packages.html">CGAL Manual - Package Overview</a>
<li>You can also access the CGAL Online Manual from the
You can access the CGAL Online Manual from the
<a href="https://doc.cgal.org/">CGAL website</a>.
</ul>
@ -39,7 +35,7 @@ in the form of a C++ library.
<ul>
<li><a href ="https://www.cgal.org/">CGAL Homepage</a>
<li><a href ="https://www.cgal.org/FAQ.html#installation">FAQ concerning Installation</a>
<li><a href ="https://www.cgal.org/FAQ.html">FAQ</a>
<li><a href ="http://www.boost.org/doc/">Boost Documentation</a>
<li><a href ="http://en.cppreference.com/w/">STL Reference</a>
</ul>

19
README.md
View File

@ -14,27 +14,12 @@ twice a year, announced on [the web site of CGAL](https://www.cgal.org/).
Getting Started with CGAL
=========================
**Since version 5.0, CGAL is header-only by default, meaning that
it is no longer necessary to build or install CGAL before it can be used.**
**Since version 5.0, CGAL is a header-only library, meaning that
it is no longer needed to build or install CGAL before it can be used.**
Head over to the [CGAL manual](https://doc.cgal.org/latest/Manual/general_intro.html)
for usage guides and tutorials that will get you started smoothly.
Compilation and Installation
============================
If you do not wish to use the header-only mode of CGAL, it is still possible to build CGAL itself.
The compilation and installation of CGAL from a sources tarball are
described in the [CGAL installation manual](https://doc.cgal.org/latest/Manual/installation.html)
and in the file [INSTALL.md](Installation/INSTALL.md) that is at the root
of any sources tarball.
You can also clone this repository and compile from your local Git repository.
This kind of compilation is called a *branch build*, and is
described in the file [INSTALL.md](INSTALL.md) that is at the root of the
Git repository.
License
=======
See the file [LICENSE.md](LICENSE.md).