Geogram options

[ramcdona]

Thanks very much for making Geogram generally available.

I am considering using Geogram to replace the CSG (Boolean operation) capability in my program. We have a hand-grown CSG engine that was developed long before modern ideas of robust geometry. It has worked for us, but as my application evolves, the importance of robustness increases. I think it will be easier to switch to a well developed and maintained library than make our own tool robust, so I'm considering Geogram.

Geogram is also attractive for me because it seems to work in a similar manner as our current approach -- where some of the alternatives have limitations that are proving challenging to work around.

I'm trying to use CMake to build. I mainly develop on MacOS, but eventually need to support (at least) Mac, Windows, and Linux. I generally build dependencies using CMake's ExternalProject_Add capability and then use FIND_PACKAGE to integrate the result into my project.

Reading the CMake files, I see a bunch of build options that don't seem to be documented in the README's. I am attempting to build with the following options...

BUILD_SHARED_LIBS=OFF
GEOGRAM_LIB_ONLY=OFF
GEOGRAM_WITH_LUA=OFF
GEOGRAM_WITH_TRIANGLE=OFF
GEOGRAM_WITH_TETGEN=OFF
GEOGRAM_WITH_VORPALINE=OFF
GEOGRAM_WITH_GRAPHICS=OFF
GEOGRAM_WITH_EXPLORAGRAM=OFF

Unfortunately, despite BUILD_SHARED_LIBS, Geogram only appears to build a dynamic library. Is it currently possible to build Geogram as a static library? I strongly prefer to build

It is not clear what functionality is lost when building with LUA, TRIANGLE, and TETGEN=OFF is enabled. Do these options cause Geogram to revert to internal alternatives, or are certain features disabled?

I was very surprised to find how much stuff was bundled as third_party libraries. I would normally expect to see these kinds of dependencies listed in the top level README's. I would also prefer to see them made optional if possible (don't use at all, use Geogram bundled library, or use external provided library) -- if they are mandatory, I would still like to see options (use Geogram bundled library, or use external provided library).

For example, my project already uses several of the dependencies bundled as third_party. I don't want to carry two copies of these dependencies in my program and I also don't want to convert everything to use the one bundled by a dependency.

When I read 'Geogram comes "with batteries installed" (nearly no external dependancies)', I thought this meant that dependencies were avoided, not that they were all rolled in together.

I know that it would complicate your build process considerably, but I would encourage you to make building Geogram as a library as modular as possible. For example, I suspect that my application currently has no need for the 'image' and 'parameterization' components. If the library was built in components - or if there were a pick-and-choose build options - then I suspect I would be able to just include what I needed from Geogram and shed a few nested dependencies while I'm at it.

[BrunoLevy]

Thank you very much for your feedback !
Here is a couple of elements of answer:

• static libraries: yes, it is BUILD_SHARED_LIBS that is supposed to select whether CMake will generate rules to build shared or static libs. I just tested and observed the same behavior as you (BUILD_SHARED_LIBS=false seems to be ignored), I will investigate and come back to you, I probably changed smthg in the build system that broke the option.
• optional components: if what you are interested in is CSG, yes, you can safely unselect the following components:
  • TETGEN: tetrahedral meshing
  • TRIANGLE: constrained Delaunay triangulation, now geogram has its own, will be deprecated soon
  • HLBFGS: numerical optimizer used by remeshing algorithm
  • GRAPHICS: geogram_gfx library, with OpenGL rendering and GUI
  • EXPLORAGRAM: algorithms for computational physics: optimal transport and hexahedral meshing
  • LEGACY_NUMERICS: numerical optimizers used by mesh parameterization and remeshing
  • LUA: Lua language scripting
  • LIB_ONLY: set it to TRUE if you want to compile the library only and not the example programs
    (and yes, documentation is missing for these options, will add it)
• modularizing: it is a really difficult subject ! my fear with too much customization option the system becomes fragmented and difficult to maintain, so I am unsure that the hassle would counterbalance the gain. The compiled library weights no more than a few megabytes, can be easily embedded in Android apps tutorial here or web pages tutorial here. By modularizing, one may gain a little percentage of the weight, for much added complexity. A possibility would be to add configuration option for compiling or not some subdirectories (for instance image and parameterization if you do not need it), maybe I'll do that.
• dependencies: it is an even more difficult subject ! I have been developping and maintaining this codebase for 23 years now, and needed to make some compromises. My number 1 guiding principles are that it should be easy to compile and lightweight usability is primary !. There are some dependencies, the full list is here. I chose to include them as submodules, because depending on the local machine, the OS etc... we would have different and complicated installation processes. On the other hand, having all the dependencies dragged in the source tree may look like "bad practice". But if you look at these dependencies, most of them are just a couple of source files (I avoid big dependencies, like BOOST, that I find too big). My point of view is that duplicating a couple of source files, although unelegant, is less problematic than having a complicated installation process. With this point of view, installation is as simple as launching one single command, on all target systems. I wish to avoid making the build system more complicated, because build systems are brittle (see for instance the option to make static libs that no longer works), and whenever something changes in the tools, it takes a significant amount of time adapting the whole structure (we have several projects depending on geogram, some opensource, some not, with continuous integration. Maintaining these systems is of vital importance, and I do not have much human resources for that, so I cannot afford taking the risk of making it more brittle.
• using geogram in an external project: there are several examples, see for instance here

That said, I am very interested in your feedback, and in your suggestions to facilitate using geogram for your project. I'll try to take into account what is a blocking point for you and make the build system evolve (as soon as it remains compatible with the constraints explained above, of course !)

[ramcdona]

Thanks for getting back to me -- and for looking into the static library issue.

I actually think we're pretty well aligned in philosophy -- I think a few small things could help users like me out a lot without adding much burden to you. A build time option to skip image and parameterization is exactly what I had in mind -- particularly if shedding some of those would then also shed other external dependencies. I would only add these options where the code already makes it easy (like these examples).

My project is set up to use bundled dependencies -- like you, I want to be able to provide as close to a 'one command' build as possible. At the same time, I also want (for example) Linux users to be able to use system-installed versions of dependencies. The key to making this work is to use CMake's FindPackage() (and the variables it sets) no matter whether you use the packaged or external version of a dependency. I.e. you can't include a dependency with a simple ADD_DIRECTORY().

Let's take zlib as an example. If geogram's CMake uses zlib as if it was discovered via FindPackage() i.e. by using ZLIB_INCLUDE_DIRS and ZLIB_LIBRARIES in its calls to INCLUDE_DIRECTORIES and TARGET_LINK_LIBRARIES, then geogram doesn't care whether you use the bundled Zlib or some external Zlib. The next trick is to set up your bundled Zlib such that it can be found via FindPackage(Zlib) -- and then make building the bundled Zlib optional.

Users who want to use the bundled Zlib just build the bundled library as part of a Libraries project build. Then the main Geogram project can FindPackage(Zlib) with a hint to search the Libraries project build directory.

Alternatively, users who want to use an external Zlib turn 'off' the bundled Zlib in the bundled Libraries project. The main Geogram project then FindPackage(Zlib) some external version of Zlib.

This approach is generally called a CMake SuperBuild or SuperProject -- because you then set up a SuperProject to first build the Libraries subproject followed by the application subproject. This gives you the one-stop build if you want it.

I haven't dug into Geogram enough to see if I'll actually run into problems with this, but one other thing that frequently bites you with duplicated libraries is namespace and linker collisions. It is easier to swallow this kind of duplication if the bundled versions of the libraries are buried behind some namespace.

[baranaydogan]

Thanks for the awesome library!

Just wanted to note that we are facing the same issue with static compilation. We follow the exact same path as @ramcdona and include geogram as an external project. But it always builds a shared library. Here are the options I am using in ExternalProject_Add.

CMAKE_ARGS -DBUILD_SHARED_LIBS=${BUILD_SHARED_LIBS}
-DCMAKE_INSTALL_PREFIX=${CMAKE_INSTALL_PREFIX}
-DGEOGRAM_LIB_ONLY=ON
-DGEOGRAM_WITH_TETGEN=OFF
-DGEOGRAM_WITH_EXPLORAGRAM=OFF
-DGEOGRAM_WITH_GRAPHICS=OFF
-DGEOGRAM_WITH_LEGACY_NUMERICS=OFF
-DGEOGRAM_WITH_HLBFGS=ON
-DGEOGRAM_WITH_TRIANGLE=OFF
-DGEOGRAM_WITH_LUA=OFF
-DGEOGRAM_WITH_FPG=OFF
-DGEOGRAM_WITH_GARGANTUA=OFF
-DGEOGRAM_WITH_GEOGRAMPLUS=OFF
-DGEOGRAM_WITH_VORPALINE=OFF
-DVORPALINE_BUILD_DYNAMIC=${BUILD_SHARED_LIBS}
)

[BrunoLevy]

Yes, I have the same problem here, if I did not break smthg elsewhere, it seems that CMake's options to build shared libs or not have changed. I'll investigate...

[BrunoLevy]

I'm stupid ! (I had forgotten the way to use my own configuration scripts), in fact it works as follows, from the configure.sh script:
To build static geogram libraries, do:

git clone --recurse-submodules https://github.com/BrunoLevy/geogram.git
cd geogram
./configure.sh Linux64-gcc
cd build/Linux64-gcc
make

To see the different possible platforms, use:

./configure.sh --help-platforms

(under Linux, default platform is Linux64-gcc-dynamic)

Hope this helps !

[baranaydogan]

I confirm that defining the VORPALINE_PLATFORM also solved the problem with the static compilation for externally added projects in Cmake too (tested with v1.8.6). Below is a working solution that I now included in our project:

ExternalProject_Add(build_geogram

CMAKE_ARGS -DBUILD_SHARED_LIBS=${BUILD_SHARED_LIBS}
-DCMAKE_INSTALL_LIBDIR=${CMAKE_INSTALL_PREFIX}/lib/${nibrary}
-DCMAKE_C_COMPILER=${CMAKE_C_COMPILER}
-DCMAKE_CXX_COMPILER=${CMAKE_CXX_COMPILER}
-DCMAKE_INSTALL_PREFIX=${CMAKE_INSTALL_PREFIX}
-DGEOGRAM_LIB_ONLY=ON
-DGEOGRAM_WITH_TETGEN=OFF
-DGEOGRAM_WITH_EXPLORAGRAM=OFF
-DGEOGRAM_WITH_GRAPHICS=OFF
-DGEOGRAM_WITH_LEGACY_NUMERICS=OFF
-DGEOGRAM_WITH_HLBFGS=ON
-DGEOGRAM_WITH_TRIANGLE=OFF
-DGEOGRAM_WITH_LUA=OFF
-DGEOGRAM_WITH_FPG=OFF
-DGEOGRAM_WITH_GARGANTUA=OFF
-DGEOGRAM_WITH_GEOGRAMPLUS=OFF
-DGEOGRAM_WITH_VORPALINE=OFF
-DVORPALINE_PLATFORM=${GEO_PLATFORM}
-DVORPALINE_BUILD_DYNAMIC=${BUILD_SHARED_LIBS}
)