CGAL
Algebraic kernel d examples fixes akobel
Verbatim copy from my mail to Laurent:
The CMakeLists didn't include the USE_MPFI, and in the testsuite the CGAL main lib itself is configured without MPFI.
I fixed that in cgal-dev/Algebraic_kernel_d_examples-fixes-akobel, and also added equivalent examples to AK_d/examples that use the RS AK. Shouldn't affect the testsuite yet, because AFAICS RS is currently not available in any configuration; but see below. It's been a while since I got something to integration, and you need to refresh my mind about the procedure: do you take care of that or should I push it there if I get your ack?
On the other front, I also made a pull request for the dockerfiles where I add NTL, RS and LEDA in the Arch Dockerfiles. I don't think RS and LEDA are easily available for any other platform. If you think it's worth to do so, I can try to find out the package names of NTL for other distros; I assume it's available as a mainstream package everywhere.
Note that, for the time being and due to the problem we are investigating, I expect the new RS AK examples in cgal-dev/Algebraic_kernel_d_examples-fixes-akobel to fail to execute properly.
Added second commit for enabling MPFI / LEDA / RS in the actual AK_d testsuite (not just the examples) as well. Note: The LEDA_USE_FILE claims to add -lX11 in the linking stage but doesn't; obviously, I'm not CMan enough to fix it in a reasonable time.
There are errors, such as: https://cgal.geometryfactory.com/CGAL/testsuite/CGAL-4.10-Ic-3/Algebraic_kernel_d_Examples/TestReport_lrineau_ArchLinux-clang.gz
The compilation errors are strange; I do not see them locally (outside of the Docker image). Will have a look asap. On the other hand, the execution errors are expected for the time being, and exactly the motivation for adding the tests; it's the interface bug between MPFR/MPFI and CGAL that Luis, Fabrice and I hunted. There was some progress on the MPFR side in the past weeks, AFAIK, but I'm not sure when we can expect to see a proper and definitive fix upstream.
Thanks. I am glad you can handle that, because that is completely out of the scope, and competences, of GeometryFactory.
(The branch also has merging conflicts with master. You might want to rebase and push--force it.)
Okay, sure. BTW, I just found out that there was a new release of MPFR during my absence. The Arch repo has the updated version since Oct 1st; could be part of the problem. Not sure if it solves the initial issue, though.
If it doesn't: What is the rationale for tests that are expected to fail for the time being? Add them, not add them, or add them with a warning message (if so, where?)?
I do not know. I like test suite results lines that are fully green (but with real tests anyway). But I must admit that I treat lines starting by Algebraic_ like those with Kinetic_: indifference.
What bother me is that, if there are headers/classes in CGAL that are known to fail, and no one bother, then that means they are not used at all...
As I am rather indifferent (before that does not seem to impact any other parts of CGAL), I let you decide. Now that most of people from Algebraic_kernel_d/package_info/Algebraic_kernel_d/maintainer are almost gone, I consider that you are the maintainer of that package anyway.
Honestly, I'm very much surprised that it never affected other parts of CGAL; AFAIK, at least the core functionality of the AK (univariate solving) is still fundamental for many higher-level algorithms. I could imagine no-one using the bivariate AK, and I can believe that hardly anyone uses the RS-based kernel (despite the fact that it offers significant speedups).
Can you give me some insight what AK instantiations your clients typically use? LEDA, anyone? RS, I doubt. GMP? Probably many, but I remember Andreas telling me that GMP is a showstopper for some customers, so I wonder what they use instead...
W.r.t. me maintaining, don't expect too much - in particular if, to the best of your knowledge, nobody else really cares about those parts. Because I don't, and I don't have a lot of time to spend on it.
I understand your stance to green test suites. If no one plans to fix the issues (and I, personally, don't), I will refrain from adding tests for the RS_Ak.
I do not know any client using the AK. Is not it used only by specific algebraic traits classes in the arrangements?
Well, if none of the clients use inputs that have algebraic curves or surfaces, I guess so. Frankly, I never checked where it might be used; I can imagine that Voronoi / Delaunay do not rely on the AK_d, but use custom predicates. And FieldWithRoot is probably hardly used, too. If you've never heard complaints about it, I assume that noone uses it...