Geogram is difficult to use in other projects because it has several mechanisms driven by global variables / command line arguments @jdumas, @Const-me, fasttetwild (please tell me if I forgot something in what follows).

This concerns:

• logger
• process
• command line arguments
• file system
• factories
• bibliography

The problems are:

• difficult for the user to know what to initialize and how
• integration in large systems (node-based,multithreaded) needs to know who initializes what and when
• in particular, modification of global state needs to be made thread-safe

Also, Geogram changes global process state:

• signal handlers
• LC_LOCALE

Redesign goals:

• client code just sees an API of classes, does not have to care about the initialization of any globals.
• there can be a global state, but it is automatically initialized (for instance, internally, by the first class
  that uses it), and it is done in a thread-safe manner
• no global process state (signal handlers, LC_LOCALE...) is modified without explicit client code request (except floating point rounding mode as required by exact predicates, but ideally it should be saved and restored after exiting the coarse-grained algorithmic blocs that use it)