Closed hoshiryu closed 3 years ago
Thanks for this detailed report. Can you refer to some repo/branch so we can have a look on your tests ?
Of course, I thought I had put them: test_install*
The build system also need some cleaning regarding cmake variables settings
This issue has been automatically marked as stale because it has not had recent activity. It will be closed in 14 days if no further activity occurs. Thank you for your contributions.
As of now the Radium-Engine cannot be installed in a proper manner (relocatable libraries / executable).
Relocatable libraries:
When using the Radium-Engine as an external lib, one has to download/configure/compile it, but there is no install procedure, and the compiled Radium libraries are not relocatable. Though this feature is not top-priority for now, it would be nice to investigate the Radium-Engine installation in order to fulfill the modern CMake way of configuring projects. The main issue I found is about the external dependencies we rely on (submodules, e.g. OpenMesh, Assimp). For now, these external libraries are built and installed in the Bundle directory through the
externalProject_add()
command of cmake, and are linked against through their full installed path. Hence, when installing the Radium libraries I end up with 2 issues:make
in my case) needs the external dependencies to be located in their install location (the one in the Bundle) which prevents the Radium libraries from being relocatable.To fix that, I tried/thought about several things, but could not end up with a working solution:
-fPIC
but I got some linker errors (not finished testing).install
and when using to the Radium libraries from another project, the linker cannot find them.find_package
(not finished testing).add_subdirectory
instead ofexternalProject_add
(not tested).Also to be mentioned, I didn't try using CPack, which might help solving this.
Relocatable executables:
Though I have been working on relocatable executables for my demonstrator, which is working fine, I had to somehow fix the resources issue mentionned in #337 . For this, I created a global variable in the Engine library that refers to the executable path (set to "./" by default), so that the executable (which overwrites this variable at launch) looks for Shaders and app-related resources folders by prefixing with this variable. I must also mention that my demonstrator is based on Qt and I used Qt-specific deployment tools to make it relocatable. I didn't try to deploy non-Qt executables, which might be more complex to do.