Michael Hoffmann (hoffmann@inf.ethz.ch)
Stefan Schirra
Sylvain Pion
This chapter gives an overview of issues related to the configuration of Cgal that allow you to answer such questions as:
Also addressed here are issues related to writing code for non-standard-compliant compilers. Compilers have made a lot of progress toward the C++-standard recently. But still they do not fully implement it. There are a few features you may assume; others you may not assume. Especially you may assume that the compiler
In the makefiles included for the compilation of every Cgal program (i.e., those to which the environment variable CGAL_MAKEFILE refers), we define command line switches that set the flags
CGAL_USE_LEDA, CGAL_USE_GMPiff Cgal is configured with Leda or GMP support, respectively.
Boost was shipped with Cgal Release 3.1, and is no longer shipped within Cgal, as it is mainstream, and already distributed with Linux and Cygwin.
Since portability and backward compatibility are a concern in Cgal, we have decided that the list of Boost libraries usable in Cgal will be decided by the Cgal editorial board. The requirements are higher when it appears in the user visible interface than when Boost code is used only internally. Requirements are even lower for code that is not released such as the test-suite. Boost libraries already accepted in the C++ Standard Library Technical Report will be the first easy candidates (these are marked [TR1] in the list below).
Finally, the policy is that if a better alternative exists in Boost and is allowed, then Cgal code must use it instead of a Cgal version (which probably must be deprecated and phased out), trying not to break backward compatibility too much.
Here is a short example on how these macros can be used. Assume you have some piece of code that depends on whether you have Leda-4.0 or later.
#ifdef CGAL_USE_LEDA #include <LEDA/basic.h> #endif #if defined(CGAL_USE_LEDA) && __LEDA__ >= 400 ... put your code for LEDA 4.0 or later ... #else ... put your code for the other case ... #endif
Every compiler defines some macros that allow you to identify it; see the following table.
|
There are also flags to identify the architecture.
|
For (good) reasons that will not be discussed here, it was decided to use C++ for the development of Cgal. An international standard for C++ has been sanctioned in 1998 [C++98] and the level of compliance varies widely between different compilers, let alone bugs.
In order to provide a uniform development environment for Cgal that looks more standard compliant than what the compilers provide, a number of workaround flags and macros have been created. Some of the workaround macros are set in <CGAL/config.h> using the macros listed in Section 12.4 to identify the compiler. But most of them are set in the platform-specific configuration files
Examples are mips_IRIX64-6.5_CC-n32-7.30 or sparc_SunOS-5.6_g++-2.95. For more information, see the Cgal installation guide.
This platform-specific configuration file is created during installation by the script install_cgal. The flags listed below are set according to the results of test programs that are compiled and run. These test programs reside in the directory
Currently (CGAL-3.4-I-181), we have the following configuration test files (and flags). The short descriptions that are given in the files are included here. In some cases, it is probably necessary to have a look at the actual files to understand what the flag is for. This list is just to give an overview. See the section on troubleshooting in the installation guide for more explanation of some of these problems and known workarounds. Be sure to have a look at Installation/config/testfiles/ to have an up-to-date version of this list.
Some macros are defined according to certain workaround flags. This is done to avoid some #ifdefs in our actual code.
#ifndef CGAL_NO_DEPRECATED_CODE CGAL_DEPRECATED void foo(int i) { ... } #endif // CGAL_NO_DEPRECATED_CODE
max BOOST_PREVENT_MACRO_SUBSTITUTION (a, b); (max) (a, b);
For SunPRO C++ member function templates with dependent return type must be defined in the body of the class.
The function parameter matching capacities of Visual C++are rather limited. Failures occur when your function bar is like
bar(std::some_iterator<std::some_container<T>>....) ... ... bar(std::some_iterator<std::some_other_container<T>>....) ...VC++ fails to distinguish that these parameters have different types. A workaround is to add some dummy parameters that are defaulted to certain values, and this affects only the places where the functions are defined, not the places where they are called. This may not be true anymore for recent VC++ versions.
class A : public B::C { typedef B::C C; };It says that the typedef is "redefinition". So such typedefs should be enclosed by
#ifndef _MSC_VER #endifThis may not be true anymore for recent VC++ versions.
Recommendations: