Add the ability to build OT as a shared or static library

[ricortiz]

It might be handy for distribution.

[erleben]

OT is a header only library?

Only deps/demos/tests needs to be builded?

If you just want to use OT in your own project, then just get the headers and add a path to the include path. If you use parts that uses any OT deps then you need to setup the deps for your project as well I guess?

[ricortiz]

This might be a bit harder and might need more thoughts, in fact I don't think is easily achievable but it can be done...

Having it packaged and distributed as:

/include/OpenTissue -> include only declarations (typical (.h) headers) /lib/libOpenTissue.so -> implementation (since OT is a template lib, this will contain template instantiations)

This will mean separating declaration from implementation (.h and .hpp or .hxx) But coming up with the machinery for doing explicit/implicit template instantiations can be very tedious. (The ITK library does it nicely but seems pretty complicated)

My initial thought was that from a business perspective... A vendor that creates some OpenTissue proprietary modules that are too close to the core to be implemented in a separate library wont be able to package those in a way don't allow it to disclose the code.

Anyhow, I classify this as a maybe.

[erleben]

There are essentially two ways of using OT. One is the business case as you describe it. Clearly having template instantiations and binary static/dynamic lib to link with is desirable for most. The other usage is for research. OT has quite generic code, traits and policies make it quite easy to combine different OT parts with each other. The possible combinations grow exponentially so making template instantiations of all possible things makes this completely infeasible.

This was one of the reasons that PROX came about as a potential OT2 replacement. We broke OT down into smaller independent sub-libs or libs with a very clear dependency that each could be packaged as a traditional library. Interfaces between libraries moved away from "type parameterization" as done with traits, policies, and type binders, instead of simple primitive data types were used as much as possible for communication between different parts, like floats/ints or arrays of these.

The idea of PROX was to make application end-users of the simulation code happier about how the code could be integrated into their own projects, and also not suffering from large compile times, and at times difficult to read template function declarations in API headers. While providing researchers and library developers with a simple well-defined scope to create new algorithms. PROX did lose a lot of the OT dependencies like Boost and GLUT was killed, many data-structures were simplified and some simulation methods were sacrificed. It turned out to be a very useful platform for research in contact force computations for rigid bodies. A lot of theses and papers have been made on top of PROX. The next evolution step we did was when more applied research came into our group. The libisl tool (heavily inspired by libigl) took some important steps to make the codebase available to non-computer science-oriented researchers. Some decisions that was made was to create a python font-end using either pure python or pybind11. In PROX we replaced Boost UBLAS/ATlast with our own SPARSE blocked matrix library, at the time CUSP, nvsparse and wiennaCL did not provide blocked matrices. The benefit of sparse was a much more natural way to do indexing and write code for assembly processes. In libisl, we felt it was resource-draining to keep our own matrix libraries alive and decided to go in on eigen3 and numpy as they integrate well when jumping between C++ and python. In PROX we also replaced GLUT with Qt, and Cg with GLSL, in libisl all demos was moved into Jupyter and using pythreejs for opengl visualization.

All this is pretty much ancient history. Neither PROX nor libisl have so far been "completed" to make any real replacement for OT. These evolutions or descendants of OT, however, demonstrate some of the lessons learned when accommodating three different types of users

1: Applied research users that do not do much programming except for a bit of high-level scripting 2: Computer science researchers that want to create new algorithms and methods 3: "Business" users that just want to have a power full and easy library to integrate painlessly into their existing projects of their own.

To be honest, OT has only ever targetted the category 2 users.

Revisiting the question of static versus shared lib raises the question of what type of users OT is intended for. If we decided to stick with 2-types then having a header-only library might be sufficient?

Merging the ideas, concepts and code from PROX, libisl and OT into one real OT2 release could be an awesome adventure, but also a quite huge task that will take some time.

I am biased towards making OT smooth operational for case 2 and 3 now. Perhaps only creating a static-shared lib with a sub-set of common instantiations, and then leave the full-blown ugly header-only mode for case 2 users? Then we can make a longer term objective of integrating the tech and lessons learned in PROX and libisl into OT to create a OT2 solution?