How to build external Apps that depends on iMSTK


Hi everyone, I’d like to know if there is an easy way to to add Cmake config files in a new (external) project so there can be easly to play with iMSTK modules. I’ve started with the provided examples but making changes takes too long to recompile. There would be very nice to have CMAKE config files so iMSTK can be accessible in a new project like:

find_package(iMSTK REQUIRED)

Create executable

add_executable(test TestApp.cpp)

Add shaders


Link libraries to executable

target_link_libraries(test ${IMSTK_LIBRARIES})

Thanks for any clue you can provide on this topic,


@renex Which files are being recompiled? Also how are you setting up your project’s settings?

To build your own project, you should follow the current examples (in particular, the CMakeLists.txt file). Of course, you can also manually link to iMSTK outside of the Examples folder, but it requires some effort. Our lab has done both in the past, but it was much easier to follow the Example projects in case we needed to change something with iMSTK.

In general, the build process only depends on the dependency order. For example, if you make a change in the “Core” folder, that will trigger a recompilation of pretty much all the projects in iMSTK. But, if you only change your example, it will compile much quicker.


Hi Nick, thanks for your reply. I’m using the original project’s settings without any modification. To clarify, as you mention the re-compiled files are just the modified ones… You are rigth, maybe it’s not necessary to link iMSTK from an outside project if you want to introduce code changes in the iMSTK inner layers. My question arises because I have the impression that the re-building process is taking too long. In my case, using an Intel Core i7 64GB Debian GNU / Linux 9.9 (stretch), the re-compiling time (time sh -c ‘make -j12’) takes around 2m22.066s. I’ve got some time improvement in 1m57.557s leaving just one of the samples. In he console there are many targets that trigger linking objects from the external lib deps to the internal ones: Core, imstk_core_test_driver, Configuring Datastructures, Geometry, imstk_geometry_test_driver, Devices, Rendering, Solvers, DynamicalModels, TimeIntegrators, SceneElements, Collision, imstk_collision_test_driver, Scene , SimulationManager, Constraints, Materials, GUIOverlay, Animation …
I’ve thougth calling iMSTK as a module or lib I could improve compilation performance but it seems is not trivial to perform. I’ll try to review if common strategies for speeding up the building process can be applied to contribute to this topic. Thanks @NickMilef!


@renex I mostly develop on Windows, in which most of the inner projects (such as Core, Device, etc.) get compiled into a .dll and then dynamically linked with the example project. So any code changes only trigger necessary dependent recompilation. It takes a few seconds to compile for me.

@sreekanth.arikatla @alexis.girault Do you have any insight into this issue on Linux?


@renex is the compile time issue you are referring to for the superbuild and its dependencies, or solely the inner build and the libraries within iMSTK? Would you happen to see if VTK is rebuilding when this occurs (I have a memory of that happening)?

We have those CMake functions called imstk_add_library and imstk_add_test, which make it super easy for anyone to set up the libraries and tests in iMSTK (usually a big issue for contributors), for example in Geometry/CMakeLists.txt. However, I believe that by using GLOB and GLOB_RECURSE, they can re-trigger the compilation even when there were no changes.

@jcfr I believe you have some good experience with that. Could you comment on it and provide suggestions? Also, did you build iMSTK before and recall poor performance during compilation? Merci :pray: