- proper indentation
- merge double occurences
- standardize location at the end block, before DOC
tested with GMP(XX), MPFR, MPFI, LEDA, RS(3), NTL and a (small) number of ways to specify library
locations via environment and CMake variables, on Debian 64bit
removed almost all occurenced (missing UseFiles). While
doing so, some CMakeLists.txt could also be simplified. In fact
many more CMakeLists.txt can be simplified, in one of two ways:
1) add external libs to CGAL_3RD_PARTY_LIBRARIES and
2) call cgal_create_single_source_program
A FindFoobar module must not include a UseFoobar file. CGAL_UseRS3 now
includes CGAL_UseMPFI, and not FindRS and FindRS3.
+ Fix also a typo in a message of FindRS3.
gcc has an option -isystem, that can replace -I. The documentation is:
-isystem dir
Search dir for header files, after all directories specified by -I but
before the standard system directories. Mark it as a system directory,
so that it gets the same special treatment as is applied to the
standard system directories. If dir begins with "=", then the "=" will
be replaced by the sysroot prefix; see --sysroot and -isysroot.
The "special treatment" means that gcc will not warn about constructions in
headers in directories pointed by -isystem instead of -I.
In the CGAL testsuite, there are a lot of warnings that comes from
third-party libraries (mostly from Boost, but also from Eigen).
This patch tells cmake to use -isystem with gcc, for all CGAL 3rd-party
directories.
to the FindQt3 module shipped with CMake
CGAL FindQt3-patched module uses the prefix QT3_ for all cache variables,
instead of just QT_. That allows to use Qt3 and Qt4 in the same project
(but for different binaries of course).
As of Boost 1.50 it is required to link Boost.System with CGAL. System
has been a Thread dependency all along and we simply never linked to
it and apparently got lucky.
Add it to the dependencies, add it in the manual and INSTALL file.
instead of including the file I've just added the general cmake makro to
check whether an item is in the list. Why does it need a macro? There should
be a list-operation for that ...
Second fix for Windows
On Windows, with auto-linking, the variables ${CGAL_LIB}_LIBRARY are
empty.
What is more, that is a bad idea to check if the libraries does exist. If
for example CGAL has been configured with WITH_CGAL_Qt4, and the CGAL_Qt4
library is not correctly created, we want a compilation error, and not just
a CMake warning saying "Please configure CGAL using WITH_${CGAL_LIB}=ON."
On Windows, with auto-linking, the variables ${CGAL_LIB}_LIBRARY are
empty.
What is more, that is a bad idea to check if the libraries does exist. If
for example CGAL has been configured with WITH_CGAL_Qt4, and the CGAL_Qt4
library is not correctly created, we want a compilation error, and not just
a CMake warning saying "Please configure CGAL using WITH_${CGAL_LIB}=ON."
| ------------------------------------------------------------------------
| r65982 | lrineau | 2011-10-20 17:49:05 +0200 (Thu, 20 Oct 2011) | 8 lines
| Changed paths:
| M /branches/next/Scripts/scripts/cgal_create_cmake_script
|
| Improvement of cgal_create_cmake_script
|
| This allows to create a CMakeLists.txt in a directory whereas the sources
| are in another directory.
|
| This will allow out-of-sources creation of CMakeLists.txt files. And, in
| the end, that will improve the branch-build.
|
| ------------------------------------------------------------------------
Make create_single_source_cgal_program() compatible with absolute paths
I have grepped for auto_link/(GMP|MFR)|AUTO_?LINK_(GMP|MPFR) and I removed
completely any support for auto-linking of GMP and MPFR from CGAL.
That is no longer necessary, nor relevant, no that we provide precompiled
GMP and MPFR libraries under standard names libgmp-10.lib and
libmpfr-4.lib.
To test in candidates:
Core
Installation
Number_types
| ------------------------------------------------------------------------
| r65557 | lrineau | 2011-09-26 16:49:02 +0200 (Mon, 26 Sep 2011) | 9 lines
| Changed paths:
| M /branches/next/Installation/cmake/modules/CGAL_UseBLAS.cmake
| M /branches/next/Installation/cmake/modules/CGAL_UseLAPACK.cmake
| M /branches/next/Installation/cmake/modules/FindBLAS.cmake
| M /branches/next/Installation/cmake/modules/FindLAPACK.cmake
| M /branches/next/Installation/doc_tex/Installation/installation.tex
|
| BLAS and LAPACK do not have header files.
|
| One implementation of BLAS or LAPACK can have a header file, but that is
| not mandatory for an implementation, and (hopefully) nothing in CGAL tries
| to include a blas.h or a lapack.h.
|
| The current revision removes mentions of BLAS_INCLUDE_DIR and
| LAPACK_INCLUDE_DIR in CGAL cmake scripts about BLAS and LAPACK.
|
|
------------------------------------------------------------------------
Reason:
For the implementation cblas/clapack, our use of that implementation does
need a header <blaswrap.h> to work.
CGAL_Boost_USE_STATIC_LIBS is now an (advanced) CMake option on all
platforms, and is stored in the generated CGALConfig.cmake. That way, its
value is proposed as the default value for the same option when programs
using CGAL are configured using CMake.
The script UseCGAL includes the module CGAL_TweakFindBoost, to define
Boost_USE_STATIC_LIBS and Boost_ADDITIONAL_VERSIONS.
Previously there was a variable CGAL_SHARED_LIBS defined by
CGALConfig.cmake. This one is now unified with CGAL_BUILD_SHARED_LIBS.
And the option CGAL_BUILD_SHARED_LIBS is only defined as an option if one
are building CGAL libraries. If CGAL_Common.cmake is included from another
project, such as from UseCGAL.cmake, then this variable is set in
CGALConfig.cmake as a regular (non-cached) CMake variable.
One implementation of BLAS or LAPACK can have a header file, but that is
not mandatory for an implementation, and (hopefully) nothing in CGAL tries
to include a blas.h or a lapack.h.
The current revision removes mentions of BLAS_INCLUDE_DIR and
LAPACK_INCLUDE_DIR in CGAL cmake scripts about BLAS and LAPACK.
*Add non-sparse matrix class (thus renamimg of the existing one)
*specialisation of the matrix class in Eigen_solver_traits according
whether this is a symmetric or asymmetric matrix
*update use-files of lapack and Taucs to get definitions
If CGAL_INSTALLATION_PACKAGE_DIR is not set in CGALConfig.cmake, then when
one compile a demo/example on Windows, Installation/auxiliary (where
precompiled version of some third party libraries should be put) cannot be
found and used. That replaces the old CMake variable CGAL_SOURCE_DIRECTORY
(before branch-build).
With this patch, when CGAL as been configured with WITH_examples and/or
WITH_demos, then the executables of examples and demos depends on the CGAL
libraries. That means if one change a file involved in a CGAL library, and
ask the rebuild of an executable, then the CGAL library will be rebuilt
first.
We declare
cmake_minimum_required(VERSION 2.6.2)
but we also use
cmake_policy(VERSION 2.8.4)
to declare that our CMake scripts are OK with all the defaults of CMake policies
as of CMake-2.8.4. That shuts down the warnings of CMake-2.8.4.
That way, we no longer need any declaration of specific policies.