A warning of clang showed me my mistake:
In file included from /no-raid/home/lrineau/CGAL/CGAL-4.4-I-10/cmake/platforms/x86-64_Linux-Fedora18_llvm-clang-with-g++-4.7/test/Kinetic_data_structures/timings.cpp:14:
In file included from /no-raid/home/lrineau/CGAL/CGAL-4.4-I-10/include/CGAL/Kinetic/Delaunay_triangulation_3.h:32:
In file included from /no-raid/home/lrineau/CGAL/CGAL-4.4-I-10/include/CGAL/Delaunay_triangulation_3.h:31:
In file included from /no-raid/home/lrineau/CGAL/CGAL-4.4-I-10/include/CGAL/Triangulation_3.h:37:
/no-raid/home/lrineau/CGAL/CGAL-4.4-I-10/include/CGAL/Triangulation_data_structure_3.h:938:7: warning: logical not is only applied to the left hand side of this comparison [-Wlogical-not-parentheses]
CGAL_assume(index_v_in_n0 <= 1);
^ ~~
/no-raid/home/lrineau/CGAL/CGAL-4.4-I-10/include/CGAL/assertions.h:86:29: note: expanded from macro 'CGAL_assume'
# define CGAL_assume(EX) CGAL_ASSUME(EX)
^
/no-raid/home/lrineau/CGAL/CGAL-4.4-I-10/include/CGAL/config.h:334:30: note: expanded from macro 'CGAL_ASSUME'
# define CGAL_ASSUME(EX) if(!EX) { __builtin_unreachable(); }
^
Trivial bug-fix.
CGAL_assume(EX) is like CGAL_assertion, but is not disabled in release
mode. In debug mode, it is similar to CGAL_assertion(). In release mode, it
uses builtins of the compilateur, like the MSVC __assume or the g++/clang
__builtin_unreachable to give an hint to the compiler that some situation
in the code cannot happen.
In order to fix such a warning from g++-4.8:
warning: typedef ‘boost_static_assert_typedef_241’ locally defined but
not used [-Wunused-local-typedefs]
then:
- create one macro CGAL_UNUSED that is "__attribute__ ((__unused__))"
with g++ or empty otherwise,
- use it after BOOST_STATIC_ASSERT in the definition of
CGAL_static_assertion.
The Intel Compiler, even when it tries to emulate the GNU/C++ compiler,
does not implement the GNU extension "statement expressions". The macro
CGAL_CFG_NO_STATEMENT_EXPRESSIONS must be defined with __INTEL_COMPILER is
defined.
When one is using the non-deprecated form of the macro, the version of
the deprecation has to be used - not the version where the original
macro appeared first.
Those cause trouble, because on MSVC the include paths for tr1
components are different from gcc. Instead of fixing up the include
paths depending on platform, just never use a tr1 component. Nothing
of value is lost compared to the boost equivalents and it removes
another code-path.
That is a followup to the following commit:
| ------------------------------------------------------------------------
| r71090 | pmoeller | 2012-08-07 13:04:32 +0200 (Tue, 07 Aug 2012) | 6 lines
| Changed paths:
| M /branches/next/Alpha_shapes_2/include/CGAL/Alpha_shape_2.h
| M /branches/next/Circulator/include/CGAL/circulator.h
| M /branches/next/Convex_decomposition_3/include/CGAL/Convex_decomposition_3/Reflex_vertex_searcher.h
| M /branches/next/Intersections_3/test/Intersections_3/bbox_other_do_intersect_test.cpp
| M /branches/next/Kernel_d/include/CGAL/Cartesian_d.h
| M /branches/next/Mesh_3/include/CGAL/IO/File_medit.h
| M /branches/next/Mesh_3/include/CGAL/Mesh_cell_criteria_3.h
| M /branches/next/Mesh_3/include/CGAL/Mesh_edge_criteria_3.h
| M /branches/next/Mesh_3/include/CGAL/Mesh_facet_criteria_3.h
| M /branches/next/Mesh_3/include/CGAL/make_mesh_3.h
| M /branches/next/Nef_2/include/CGAL/Bounded_kernel.h
| M /branches/next/Nef_2/include/CGAL/Nef_polyhedron_2.h
| M /branches/next/Nef_3/include/CGAL/Nef_3/ID_support_handler.h
| M /branches/next/Nef_3/include/CGAL/Nef_3/Infimaximal_box.h
| M /branches/next/Nef_3/include/CGAL/Nef_3/vertex_cycle_to_nef_3.h
| M /branches/next/Nef_3/include/CGAL/Nef_polyhedron_3.h
| M /branches/next/Nef_3/test/Nef_3/nef_union_error_llvm.cpp
| M /branches/next/Nef_S2/include/CGAL/Nef_S2/SM_overlayer.h
| M /branches/next/OpenNL/include/CGAL/OpenNL/blas.h
| M /branches/next/Periodic_3_triangulation_3/include/CGAL/Periodic_3_triangulation_3.h
| M /branches/next/Point_set_processing_3/include/CGAL/mst_orient_normals.h
| M /branches/next/QP_solver/include/CGAL/QP_solver/QP_functions_impl.h
| M /branches/next/STL_Extension/include/CGAL/iterator.h
| M /branches/next/Segment_Delaunay_graph_2/include/CGAL/Segment_Delaunay_graph_simple_site_2.h
| M /branches/next/Subdivision_method_3/include/CGAL/Polyhedron_decorator_3.h
| M /branches/next/Subdivision_method_3/include/CGAL/Subdivision_mask_3.h
| M /branches/next/Surface_mesher/include/CGAL/Surface_mesh_default_criteria_3.h
| M /branches/next/Voronoi_diagram_2/include/CGAL/Voronoi_diagram_2/Adaptation_traits_functors.h
| M /branches/next/Voronoi_diagram_2/include/CGAL/Voronoi_diagram_2/Default_site_inserters.h
| M /branches/next/Voronoi_diagram_2/include/CGAL/Voronoi_diagram_2/Default_site_removers.h
|
| WARNFIX: Silence a good part of unused variable/parameter warnings.
|
| Wextra results in a dreadful wall of yellow in the test-suite and is
| scary when using CGAL. Reduce some of the noise by silencing the
| obvious cases with CGAL_USE or comments.
|
| ------------------------------------------------------------------------
The reason is that everything from CGAL/Testsuite/ is removed in public
releases (that was discussed at a CGAL developers meetings, long ago). That
means that r71090 introduced compilation errors undetectable by the tests
of internal releases. I hope that the minutes of that developers meeting
say that I was against the removal of headers between internal and public
releases! -- Laurent Rineau
| ------------------------------------------------------------------------
| r68020 | cjamin | 2012-03-12 18:27:30 +0100 (Mon, 12 Mar 2012) | 1 line
|
| To be able to build CGAL on MSVC11
|
------------------------------------------------------------------------
It adapts CGAL CMake scripts and CGAL auto-link headers to MSVC2011.
Thanks to Clement Jamin, from Inria, for the patch.
We adopt the naming scheme of Boost libraries, with the "lib" prefix for
static libraries. And with the CGAL_VERSION as suffix.
For example, static libraries will be named:
libCGAL_Qt4-vc100-mt-gd-3.10-Ic-123.lib
and DLL will be named:
CGAL_Qt4-vc100-mt-gd-3.10-Ic-123.dll
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
Marc Glisse
Laurent Rineau
Laurent Rineau
Philipp Möller
Philipp Möller
Laurent Rineau
Sébastien Loriot
Andreas Fabri