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.
Those two lines must be present and maintained in all our CMakeLists.txt
files (the one for the libraries, and also the one for examples and demos,
and maybe tests).
The documentation of CGAL says that the minimal version of CMake must be
CMake-2.6.2.
- change cmake_minimum_required to VERSION 2.6.2
- no longer any need for the policy CMP0003 (was for 2.4.x)
- no longer any need for CMAKE_ALLOW_LOOSE_LOOP_CONSTRUCTS (was for 2.4)
*identity test of span must be done using directions
*add a test for identical but opposite spans
*add missing make_exact calls
*special case of has_same_support for vertical bezier
*special case of _is_in_range for vertical bezier
*add a do-while loop to increase precision in _exact_vertical_position
*fix a bug in resultant computation
*a missing originator when using split with an endpoint of a bezier.
this happen for example when computing the arrangement of a vertical bezier
and another one having its start point on the vertical one
*fix bug in skewbbox intersection in the case of a vertical bezier
In particular remove UNTESTED_XXXXXXXXXXX unused variable that possibly hide true warnings.
In those cases, the string printed while executed now starts with "NOTE: ".
*CGAL internal code no longer rely on depecrated features
when it was determined using a control point during de Casteljau subdivision
(when we try to compute approximated intersection points).
update test-suite to set to 0 the multiplicity of bezier segments sharing an endpoint,
add an example of 2 bezier bezier tangent at a control point found during de Casteljau
subdivision. Also add an example of an intersection point of two bezier segments
which multiplicity is 1.
of bezier curves with parameters in range [0,1]. I need to change also the pairing
of parameters as a parameter s in the range [0,1] for one curve may correspond to
a parameter t outside the range (so the number of s and t values may be different).
To handle this problem, we choose the list with less parameter values and make the
pairing with the other values.
Note that on the test-suite, this divided by 3 the time needed to compute
the intersection of the two polygons.
After checking, it appears that everything is done at the polynomial
level in the code and should be fine (after having fixed the solver
to find roots in [0,1]). Modify a test file to use duplicated control points.
*forgot to generate exact representation of input in case they
were just approximations.
the bezier is a vertical or horizontal segment.
This fix showed a probable bug in expected result of the testsuite:
In the case the bezier is a vertical segment,
compare_y_at_x now returns EQUAL when the query point
is inside the segment.
the lowest incident halfedge is he_before, we should return NULL
(I removed the test he!=he_before as if he he_left_low is updated
several time with the same v_min, the fat that he_before==he_left_low
can be detected).
*update testsuite to test this case.
_find_leftmost_vertex_on_open_loop. The lowest halfedge incident
to the left most vertex was incorrectly detected in some configurations
(see the example added in test_insertion.cpp). The fix consists in explicitely
testing in case the left most vertex is visited several times that the halfedge
is really the lowest one using functor Compare_y_at_x_right_2.
*update test_insertion so that failure is detected
in the case where the evaluation is made at point where the tangent
to the bezier curve is vertical. In that case the comparison
relies on the sign of the derivate of the y coordinate evaluated at
that point. It must take into account the fact that the x-monotone
bezier curve is directed_right or not (ie x increases or decreases with t)