CGAL undocumented dependencies

[marcocecchiscmgroup]

While trying to build CGAL with cmake, I downloaded/got/built all the dependencies in sort of a trial&error fashion, as long as they were reported in the logs as warnings/errors etc.
A good starting point was this CGAL manual page: 3rdparty.

However, it looks as though a bunch of dependencies, as they look like by their cmake variable names, are not documented. I am referring to:

VTK/VTK_DIR (ok, this a well known one)
3MF/3MF_INCLUDE_DIR
ESBTL/ESBTL_INCLUDE_DIR
IPE/IPE_DIR (what is it, where to get it?)
ITK/ITK_DIR (what is it, where to get it?)
ITT/ITT_INCLUDE_DIR (what is it, where to get it?)
LIBSSH/LIBSSH_INCLUDE_DIR (very famous, but not mentioned anyway)
OpenMesh/OpenMesh_DIR (seems pretty important, aint't?)

Even if some of these are most probably needed for the sake of examples and demos, it is equally important to have them well documented. Of course one cannot tell before actually building it all.

When it comes to building graphic libraries, for example, my reference is VTK, whereby you get it, run cmake, open visual studio and everything automagically compiles, run and works.

Finally, after reading this from the cmake log:

Using header-only CGAL

I am kindly asking if there is a - maybe 'old' - way of building CGAL as a library, possibly static. I mean, header-only libraries have their disadvantages and are especially meant for different kind of projects, with less dependencies. In this way the responsibility for all this plethora of dependencies is deferred to the end user project, which typically doesn't care, basically.

[lrineau]

I am kindly asking if there is a - maybe 'old' - way of building CGAL as a library, possibly static. I mean, header-only libraries have their disadvantages and are especially meant for different kind of projects, with less dependencies. In this way the responsibility for all this plethora of dependencies is deferred to the end user project, which typically doesn't care, basically.

CGAL is a library of C++ templates. There is not really anything that can be precompiled. In the old days, there was a very few bits of CGAL that were precompiled (support for colors, random numbers, I/O for 3D images...), and it was a pain to maintain, for almost no advantages. The issue with 3rd party dependencies was the same, because the C++ templates were using them.

A lot of the third party dependencies are only required by tiny bits of CGAL. The only hard dependency is the Boost library headers. Another pretty important one is the couple GMP/MPFR, that is used by the CGAL::Epick kernel, with default settings (one can use other exact number types).

Some of the dependencies you mentioned (ssh/openmesh/ipe/itt) are only used by applications in the demo/ sub-directory. And for most of the cases those dependencies are optional. That is not even part of what we call CGAL: they are user applications.

ITT is Intel ITT, only used for debugging/profiling in CGAL Mesh_3. ITK is https://itk.org/, used to process 3D images in only one function template of CGAL: CGAL::Mesh_3::generate_label_weights. IPE is https://ipe.otfried.org/, and quite anecdotal for CGAL: we have a new demo programs that are Ipe plugins.

I wonder why you even try to install all those dependencies.

[marcocecchiscmgroup]

Some of the dependencies you mentioned (ssh/openmesh/ipe/itt) are only used by applications in the demo/ sub-directory.

Sure, in fact I would like them to try them out.

I wonder why you even try to install all those dependencies.

Well, maybe because of this message in demo/Polyhedron?

**Missing optional packages:

• MPFI
• ITT
• OSQP
• IPE (required version >= 7)
• LEDA
• LibSSH, A library implementing the SSH protocol on client and server side.
  Required for loading (saving) a scene to (from) a distant server.
• OpenCV, A library for real-time computer vision.
  Enables the random forest predicate for the classification plugin.
• LASLIB, A library for LIDAR I/O.
  Required for reading or writing LAS files.
• ITK
• VTK, A library for image processing.
  Can be used for I/O (DICOM, VTU, VTP.
• OpenGR