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.
When the value of the Boolean cache variable BUILD_SHARED_LIBS is modified,
there was a bug that the variable CGAL_LIBRARY_NAME,
CGAL_Core_LIBRARY_NAME, CGAL_Qt4_LIBRARY_NAME, and so on, were not
updated. As a consequence, the file CGALConfig.cmake produced in the
installation directory was not correct: it was referring to .so files
whereas the installed binaries were .a files, or the reverse.
This patch fixes the issue.
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."
Eric Berberich
Laurent Rineau
Efi Fogel
Ophir Setter
Philipp Möller