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:
@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.
@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
@alexis.girault most of the time is spent in the iMSTK objects despite VTK target also triggers some linking. I’ll try to check the Cmake utilities out as you suggest but I’m not a Cmake expert. Regarding GLOB and GLOB_RECURSE they are being used in several CMakeLists.txt files around the project. I share two links containing the console outputs so you can compare with your building process maybe you can find some differences with what you have. I’ve got them after running ‘make -j$(nproc)’ in a new iMSTK-build folder:
then, re-running the command without any code modification gives:
I’ve also tried setting the building process with ninja but unfortunately I’ve got stuck due to a multiple rules issue:
ninja: error: build.ninja:4070: multiple rules generate ExternalData/Data/asianDragon/asianDragon.bou-hash-stamp [-w dupbuild=err]
so I can’t check if performance improves…
Check the new repo createad at Kitware’s Gitlab where there can be found some of the snippets of the Example folder for linux distros https://gitlab.kitware.com/renexdev/imstk-snippets from outside the main project.
Yours,
I’m testing the last version with the CMAKE improvements, looks great!. I’ll take a look to the new call functions for finding the libs and headers in the .cmake files. A problem that I run into in linux was the find_path take the default installed system libs intead of the external dependences, to deal with that I added extra flags in the HINTS, i.e NO_DEFAULT_PATH, NO_SYSTEM_ENVIRONMENT_PATH and NO_CMAKE_SYSTEM_PATH.
I’ve also made a minimal modificacion to get CMAKE found PhysX modules, check the note at
I’m very excited with the adoption of PhysX in the project, we will be working during next year to continue getting a more deep insight into the iMSTK framework and to prototype some implementations on iMSTK, so we will keept tuned.
We’re also very enthusiastic with the vulkan backend Renderer that I could successfully compiled in linux, so we can start playing with volume rendering implementations. When I return from vacations I’ll take it back and share our progress.
Yours,
Did you have to modify imstkFind.cmake ?
I do use the NO_DEFAULT_PATH, which should negate the need for any other NO_XXXX_PATH variables, as when NO_DEFAULT_PATH is specified, then no additional paths are added to the search.
In the build directory, they will be a folder called install which should have all you need to build an external application. This install folder is populated with the libs/dlls and headers of imstk and all its dependencies.
imstk_add_library is used to create an imstk library
