(sorry for the late answer, I never received your last comment and only
noticed it by chance on the web)
I was already about to upload a modified package, but did not manage to
do it before my vacation. Now thinking a bit more about the problem I'm
no longer sure the outlined solution is the correct one.
I am not certain either, but it seemed to make sense to me.
If GMPXX/MPFI/NTL support is enabled when building the library itself
(and hence defining CGAL_USE_GMPXX/MPFI/NTL in compiler_config.h), won't
every application using CGAL get a link dependency to these libraries
(assuming it includes a header with #ifdef CGAL_USE_GMPXX/MPFI/NTL)?
Only if it really uses it. And it should only use it if that's the best
option. For instance, if you compute a Delaunay triangulation with the
epick kernel, I don't think it picks up any dependency on any of those 3
libraries. (cmake might link with the whole world by default, or instead
forget to link with mpfi, but that's a different issue)
For example, there is one example that does no longer build because of
that (sorry, don't know the name anymore, but I think the module starts
with "A").
Looks like a bug in the build scripts.
Isn't the correct solution to enable only support for those libraries
that affect the CGAL library itself, and to ask applications using CGAL
to add additional -DCGAL_USE_GMPXX/MPFI/NTL flags if they want to make
use of these features? (Basically the status quo.)
Then you could disable MPFR. Ah, no, GMP is needed for CORE, and cgal
can't enable GMP without MPFR... But you could still disable GMP and MPFR
after the fact, patching compiler_config.h so that it enables nothing.
It is a matter of compromise. Personally, I'd like to be able to compile a
program that uses gmpxx without having to pass weird flags like
-DCGAL_USE_GMPXX, -lgmpxx should be enough (and possibly not even needed
if I don't do I/O, but then even if CGAL_USE_GMPXX is not defined,
-lgmpxx may be needed for I/O on gmp types...). And if my program
mysteriously becomes twice as slow because I somehow forgot to enable mpfi
and cgal thus silently uses a work-around, that's not so good either. And
gmpxx/mpfi are small when you are already linking with mpfr+gmp.
But I can understand people wanting to control the dependencies of their
programs and not just notice in the end which random set of libraries was
magically used.
So, your choice ;-)
--
Marc Glisse
PS (unrelated to this issue): it would be nice if you got a chance to
start on the multi-arch transition, even if boost/qt prevent you from
going all the way for now.
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
