Library/Target Modularization
This has been discussed for awhile, but it would be nice to split up iMSTKs libraries in a way that doesn't involve us linking to the entirety of all of them in every example. Usually
target_link_libraries(myProject PUBLIC SimulationManager)
is done which transiently gives all other libraries. To reduce program bloat it's nicer if you can split things up such as done with Filtering. Filtering exists independent of the rest of imstk. As such you either link to it or not.
target_link_libraries(myProject PUBLIC SimulationManager Filtering)
This not only reduces program sizes but also encourages developers to keep their code modular. It should also allow us to keep iMSTK more modular to support things like extensions/modules (maybe even remote ones). There are many ways to do such a thing but it generally involves splitting up abstract base classes in separate libraries from the implementations.
- For example, SPH could be entirely wrapped in its own module (or modules), providing SPHObject, SPHModel, various SPH related interactions.
- Another example is how FilterCore exists separately from Filtering allowing linkage to the base abstract class without all the rest of the filters. Allowing parallel builds.
Lastly this should also aid the build. For example right now we build these targets in this order:
DynamicalModels -> SceneEntities -> Scene
Where DynamicalModels builds SPH, PBD, FEM, etc code. Which is funny because the Scene doesn't know anything about PBD or SPH, and shouldn't. So why make it depend on it? You could instead have
DynamicalModels -> SPH
DynamicalModels -> PBD
DynamicalModels -> FEM
DynamicalModels -> SceneEntities -> Scene
Where DynamicalModels only builds the base abstract class for dynamical models. SPH, PBD, FEM can then all build in parallel. Similar things can be applied all over iMSTK.