Closed ukabuer closed 4 years ago
And ospcommon
header files like ospcommon/math/AffineSpace.h
cannot be found when including ospray/ospray_cpp.h
, it seems that these headers are not bundled into the precompiled package for Linux
This is definitely an oversight (OSPRAY_INSTALL_DEPENDENCIES
needs to be off for prebuilt binaries).
For ospray_cpp
, there will need to be some sort of strategy for what to do with ospcommon data types. At the very least, ospcommon::ospcommon
should be a PUBLIC
linked target to make sure CMake properly checks that everything ospray_cpp
needs is there.
In the mean time, would running the superbuild locally give you a "package" to work with?
Oh, it looks like we no longer have a target for ospray_cpp
either! Looks like this needs cleaned up quite a bit.
I can solve the first problem by manually changing OSPRAY_INSTALL_DEPENDENCIES
to ON
in ospray-2.1.0.x86_64.linux/lib/cmake/osprayConfig.cmake
, and then CMake can figure out where those dependencies locate.
(I didn't install ospray to my system PATH and just set -D ospray_DIR=/ospray-2.1.0.x86_64.linux/lib/cmake/
when configuring CMake after extracting the prebuilt archive.)
As for the superbuild, I feel like it would take me a long time so I choose to continue with my current solution :)
I guess I see a related issue with the release-2.1.x
branch built locally with the superbuild. In blospray's main cmakelists.txt I use find_package(ospray 2.1.0 REQUIRED)
to detect ospray (which is found) and then use target_link_libraries(libblospray PUBLIC dl Threads::Threads ospray::ospray ..)
later on. But I get multiple cmake errors that ospcommon::ospcommon
is missing, e.g.
-- Configuring done
CMake Error at core/CMakeLists.txt:45 (add_library):
Target "libblospray" links to target "ospcommon::ospcommon" but the target
was not found. Perhaps a find_package() call is missing for an IMPORTED
target, or an ALIAS target is missing?
Looks like adding find_package(ospcommon 1.3.1 REQUIRED)
at least solves the configuration issue, although that's a bit of hack.
Unfortunately that leads to https://github.com/ospray/ospcommon/issues/2 for me, specifically an attempt to link to ospcommon_tbb
(which does not exist). So looks like the superbuild is not an option at the moment and patching OSPRAY_INSTALL_DEPENDENCIES
to ON
in the binary version is the only way for now to use 2.1.0? But that fails because of the missing ospcommon::ospcommon
target above, so bit of a catch-22.
I figured out where the reference to ospcommon::opscommon
is coming from: I'm linking against ospray::ospray_testing
to reuse some of the testing scenes. Apparently, that pulls in ospcommon, but it isn't defined.
Edit: doh, setting OSPRAY_INSTALL_DEPENDENCIES
back to OFF
fixes this
Fixed in v2.1.1.
I am trying to use the precompiled OSPRay 2.1.0 for Linux in my project but CMake generates errors for not finding
ospcommonConfig.cmake
orFindospcommon.cmake
here:https://github.com/ospray/ospray/blob/7c01f46bb9ee9f7ebcb95e116bffd39d23f5a2f3/cmake/ospray_cmake_config/osprayConfig.cmake.in#L138
Maybe
OSPRAY_INSTALL_DEPENDENCIES
should be set toON
in the build script for Linux since all dynamic libraries are bundled into the final tar.gz file?https://github.com/ospray/ospray/blob/7c01f46bb9ee9f7ebcb95e116bffd39d23f5a2f3/scripts/release/linux.sh#L110