OCE-libraries-release.cmake 3rd party libs are referenced to local build dir, not install dir

[sanderboer]

Hi,

In $OCE_INSTALL/cmake/OCE-libraries-release.cmake 3rd party references are referred to the local build dir.

This can be found in the OCE-0.17-MINGW32 release:

D:/Devel/freetype-2.3.5-1-bin/bin/freetype6.dll
in for instance:

set_target_properties(TKOpenGl PROPERTIES
  IMPORTED_IMPLIB_RELEASE "${_IMPORT_PREFIX}/Win32/lib/libTKOpenGl.dll.a"
  IMPORTED_LINK_INTERFACE_LIBRARIES_RELEASE "TKernel;TKService;TKV3d;glu32;opengl32;D:/Devel/freetype-2.3.5-1-bin/bin/freetype6.dll;vfw32"
  IMPORTED_LOCATION_RELEASE "${_IMPORT_PREFIX}/Win32/bin/libTKOpenGl.dll"
  )

I replaced:
D:/Devel/freetype-2.3.5-1-bin/bin/
with:
${_IMPORT_PREFIX}/Win32/lib/

and all was well.

I recompiled oce-git master this week with msys-ming-w64 on windows 10 and this behavior was still present.

kind regards,
Sander

[ghost]

I can confirm this, however not sure where to look to fix.

[tpaviot]

The files oce-libraries.cmake and oce-libraries-release.cmake are automatically generated by cmake.

Every third pat library for manually specified paths at cmake configuration time will be exported as is. I don't know if it's possible to set a relative path.

[Warmyone]

Im not sure if it is helpful for the issue but CMake does have generator-expressions. $<INSTALL_INTERFACE:...> and $<BUILD_INTERFACE:...> could be useful.

Instead of

target_link_libraries(${TOOLKIT} optimized ${lib})

, which to my knowledge contains freetype, it could be

target_link_libraries(${TOOLKIT} optimized
   $<BUILD_INTERFACE:${lib}>
   $<INSTALL_INTERFACE:%relativePath%>
)

The relative path would need to be composed platform dependent or the libs would need to be copied into a common location instead of e.g. Win64/lib. Here is a more detailed description of the feature.

[Warmyone]

On another project I ran into this bug again, so here is my attempt to fix it (OCE-0.18.3...Warmyone:OCE-0.18.3_relative-cmake-install-paths). I don't know the proper way to contribute, so should I just create a request from my fork? As a side effect the changes will make the OCE binaries portable (at least my locale build was) and one could also provide prebuild binaries.

There is a related issue (https://gitlab.kitware.com/cmake/cmake/-/issues/17756) at CMake. I also posted my fix there and asked for better alternatives and for further discussion stated the pitfalls I know of.
The solution is based on generator-expressions and configure_package_config_file.

Changes:

• added FREETYPE_BINARY path to use different lib/bin directories [fixes not copying dll's]
  • added code to be compatible with existing behavior or empty binary path
• use the lib name given with the FREETYPE_... variables, if existing [e.g. fixes not copying vtkfreetype-X.Y.lib]
  • defaults to previous behavior if the given variable is a directory
  • if the freeType files are in their default location, setting FREETYPE_LIBARY to the freeType directory is now sufficient [new]
• use configure_package_config_file instead of configure_file for ProjectConfig.cmake.in [fixes absolute path]
  • use the @PACKAGE_...@ feature to generate relative freeType paths
  • use that feature for other relative variables in ProjectConfig.cmake.in
• add a imported interface target for freeType to link against, done in an separate cmake file [fixes accessibility of the relative path at build and install time]
  • include that cmake file in CMakeLists.txt (for build time)
  • insert it's content into a tmp version of ProjectConfig.cmake.in and use that as input for configure_package_config_file (for install time)