No absolute paths for dependants

[ahoereth]

By no means sure this is the correct approach.. Cmake documentation on this is rather confusing because there appear to be many different ways of achieving the same thing.

Result in deps/lib/cmake/SickLMS5xx/SickLMS5xxTargets.cmake:

# Create imported target SickLMS5xx::SickLMS5xx
add_library(SickLMS5xx::SickLMS5xx SHARED IMPORTED)

set_target_properties(SickLMS5xx::SickLMS5xx PROPERTIES
  INTERFACE_INCLUDE_DIRECTORIES "${_IMPORT_PREFIX}/include/"
  INTERFACE_LINK_DIRECTORIES "${_IMPORT_PREFIX}/lib/"
  INTERFACE_LINK_LIBRARIES "Eigen3::Eigen;Threads::Threads;pcl_common;pcl_octree;pcl_io;Boost::system;Boost::filesystem;Boost::iostreams;Boost::serializ
ation;VTK::ChartsCore;VTK::CommonColor;VTK::CommonComputationalGeometry;VTK::CommonCore;VTK::CommonDataModel;VTK::CommonExecutionModel;VTK::CommonMath;V
TK::CommonMisc;VTK::CommonTransforms;VTK::FiltersCore;VTK::FiltersExtraction;VTK::FiltersGeneral;VTK::FiltersGeometry;VTK::FiltersModeling;VTK::FiltersS
ources;VTK::ImagingCore;VTK::ImagingSources;VTK::InteractionImage;VTK::InteractionStyle;VTK::InteractionWidgets;VTK::IOCore;VTK::IOGeometry;VTK::IOImage
;VTK::IOLegacy;VTK::IOPLY;VTK::RenderingAnnotation;VTK::RenderingCore;VTK::RenderingContext2D;VTK::RenderingLOD;VTK::RenderingFreeType;VTK::ViewsCore;VT
K::ViewsContext2D;VTK::RenderingOpenGL2;VTK::RenderingContextOpenGL2;VTK::GUISupportQt"
  INTERFACE_SYSTEM_INCLUDE_DIRECTORIES "include/"
)

dislike that all the vtk thingies are listed there instead of only the top-level dependencies. That appears to be a result of this line in the CMakeLists.txt:

target_link_libraries(${PROJECT_NAME} PUBLIC ${LIBS})

[themightyoarfish]

but this would be wrong. client projects need to include pcl include dirs if they want to make use of pcl.hpp shipped with this project.
same with libs

[ahoereth]

See the description of the PR, looks like it still produces the correct includes. Thing is we just cannot use absolute paths to where the includes "were" during install if it should be relocatable.

[themightyoarfish]

where do you see the correct pcl dirs being included? did you try with pcl being in a different prefix than this library?

[ahoereth]

Yea its not in there, but if it contains a path which does not exist anymore, it errors.

[themightyoarfish]

yes no doubt, but I'm not sure what the fix is.

[themightyoarfish]

shifting the inclusion and linking of transitive dependencies onto all client projects can't be the way to go.
what is the before-state of this PR?

[themightyoarfish]

it make sense to make the PCL links private as you did above, but the generated SickLMS5xxConfig.cmake should still have the find_dependency() calls to resolve this stuff at configure time, does including them here lead to any hardcoded paths???

[themightyoarfish]

i had thought that gets executed when you call find_package(Sick), so there should not be any install paths in there.