I am using superbuild to build all the dependencies. I followed the setup on Windows where <path_to_cmb_superbuild_install>/install/bin and <path_to_cmb_superbuild_install>/install/Python are added to PATH and <path_to_cmb_superbuild_install>/install/Python is also added to PYTHONHOME.
After this, I can build CMB based application and execute it without any issue.
What I don’t understand is how CMake finds ParaView or SMTK or any other libraries which were built from superbuild. I only added <path_to_cmb_superbuild_install>/install/bin to PATH. There is a subfolder cmake under <path_to_cmb_superbuild_install>/install/bin. But it is empty. I see all the config.cmake files which find_package() is looking for is inside C:\cmb\RelWithDebInfo\install\lib\cmake. But I didn’t even add C:\cmb\RelWithDebInfo\install\lib to my PATH.
Hi Yang,
Basically this is just how the superbuild is setup to work. Each project in the superbuild is designed to install everything needed into the build/install directory, so that any project that depends on it can find the headers/libs needed. So ParaView puts all the headers, libs, dlls and binaries it built into the install dir, and then SMTK looks there because it is set up that way by the superbuild.
This convenience is broken for dependencies if you choose to do a “developer build”, because that project no longer installs its headers/libs into the superbuild’s build/install directory. So you need to tell any dependencies explicitly where that project is. For example, if you do a developer build of SMTK, if you then want to build aeva-session which depends on it, you would need to add -Dsmtk_DIR:PATH=C:/cmb/smtk/build with the SMTK build dir to your cmake command.
Thanks! I think I got it. To quote from find_package() documentation, Path entries ending in /binor/sbin are automatically converted to their parent directories: So, this is a cmake feature. I was scratching my head on why it finds build/install/lib as I only added build/install/bin to my PATH.
Regarding the developer build, if I choose developer mode, does it allow me to use Debug configuration? It seems like superbuild only supports Release and RelWithDebInfo
The PATH environment variable is not used by CMake, I don’t think - it is just used when running your app to find DLLs. I think the docs are referring to CMAKE_MODULE_PATH, which is set by the superbuild.
As for using Debug, not on Windows, unfortunately - you must choose either the debug runtime or the release runtime consistently for all libraries in your project, otherwise you get linking errors. The best bet is to go with RelWithDebInfo for everything. This limitation does not apply on Mac/Linux.
I am having the issue which doesn’t load OpencascadeSession. I enabled OpenCascadeSession in superbuild and but when I loaded that plugin in the application, I got the following message.
I am using RelWithDebInfo configuration and this message doesn’t help much. I was wondering that if debug configuration could throw out more information?
when I build superbuild project, it will add build/install/lib to CMAKE_MODULE_PATH such that an external project, e.g., aeva-session, can find the dependencies. Is this correct?
I just tested it. If I removed build/install/bin from PATH and reconfigure aeva-session, it can’t find smtk package. What I have observed so far: build/install/bin in PATH environment variable → can find dependencies build/install/bin not in PATH environment variable → can’t find dependencies
Just curious what is going on under the hood.
Huh, I didn’t know that, interesting. What I believe is happening is that by adding to your PATH you are making those projects available as system projects - i.e. installed globally, like you might install a system Python or system Qt. This works, but makes it harder to swap versions for multiple builds.
I don’t think a Debug build will help with the OpenCascade plugin load. It looks like it’s missing a dependency. I think if you make a dummy project and dummy debug config to launch the app, it should tell you more. If not, you can look at the open cascade DLL with a dependency walker, like depends.exe, to see what it might be missing.
