Dependencies handling in cmake config

[mitsch]

When installing dlib, I see that the exported cmake config has dependencies with hardcoded paths imprinted. This causes any other environment setting to keep the dependencies at the same place.

In my case, I have a docker where I install dlib with cudnn at /usr/libx86_64-linux-gnu. On the system I want my dlib to deploy to, I have cudnn at /opt/cudnn-7.

Usually cmake allows to abstract from this path-hardcoded dependency by letting dlibConfig.cmake find cudnn a second time (when find_package(dlib ...) is called).

Is there a reason why this flexibility is not implemented? (besides the comfort of not explicitely declaring the dependencies a second time)

[xsacha]

## DLib looks here
 SET(CMAKE_PREFIX_PATH "${CMAKE_PREFIX_PATH} ${PREBUILT}/cuda/")

[mitsch]

I reckon that I did not communicate clearly what my issue is.

In which file do I find this line? It only sets the CMAKE_PREFIX_PATH, but I'm talking about dependencies, so anything about set_target_properties or target_link_libraries.

As far as I have understood it: In the dlibConfig.cmake from my unmodified master installation (commit 61a021c932b74e591ce6a57ec1efa2dd59f33a7f), the dlib.cmake in the same folder will be called. In that dlib.cmake file:

set_target_properties(dlib::dlib PROPERTIES
  INTERFACE_COMPILE_FEATURES "cxx_rvalue_references;cxx_variadic_templates;cxx_lambdas;cxx_defaulted_move_initializers;cxx_delegating_constructors;cxx_thread_local;cxx_constexpr;cxx_auto_type"
  INTERFACE_COMPILE_OPTIONS "\$<\$<COMPILE_LANGUAGE:CXX>:-Wreturn-type>"
  INTERFACE_INCLUDE_DIRECTORIES "${_IMPORT_PREFIX}/include"
  INTERFACE_LINK_LIBRARIES "/usr/local/cuda/lib64/libcudart_static.a;-lpthread;dl;/usr/lib/x86_64-linux-gnu/librt.so;-lpthread;/usr/lib/x86_64-linux-gnu/libnsl.so;/usr/lib/x86_64-linux-gnu/libSM.so;/usr/lib/x86_64-linux-gnu/libICE.so;/usr/lib/x86_64-linux-gnu/libX11.so;/usr/lib/x86_64-linux-gnu/libXext.so;/usr/lib/x86_64-linux-gnu/libpng.so;/usr/lib/x86_64-linux-gnu/libz.so;/usr/lib/x86_64-linux-gnu/libjpeg.so;/usr/lib/libatlas.so;/usr/lib/libcblas.so;/usr/lib/liblapack.so;/usr/local/cuda/lib64/libcublas.so;/usr/lib/x86_64-linux-gnu/libcudnn.so;/usr/local/cuda/lib64/libcurand.so;/usr/local/cuda/lib64/libcusolver.so;-fopenmp"
)

In that last line, the dependencies are set for the already-compiled dependency dlib. My issue, if I deploy the installation to another system, the dependencies of dlib might reside at a different place. Even as suggested above, setting the CMAKE_PREFIX_PATH, will not change the fact that hardcoded paths are set as dependencies.

From my little experience in cmake 3, I expected some find_package or find_dependency in the dlibConfig.cmake and the setting of targets instead of hardcoded paths as dependency of target. In such case, every time, find_package(dlib ...) is called, find_package of the dlib dependencies will be called again.

Is there any rational behind not doing it that way, besides not coming around to do so far?

(thank's so far for your help)

[xsacha]

CUDNN is not part of or distributed with dlib, so the CUDNN would need to be found again on the system where it is being imported, right?

[mitsch]

Exactly.

I understand that dlib so far assumes that it will be always at the path where cmake found it at configuration time of dlib compilation/installation. In my case that is /usr/lib/x86_64-linux-gnu/libcudnn.so. Shipping all libraries/headers/cmakeConfigs to another system, cudnn needs to be found at a different place, but dlib.cmake is assuming thtat libcudnn.so is at /usr/lib/x86_64-linux-gnu/libcudnn.so. At least it is hardcoded in my ${CMAKE_INSTALL_PREFIX}/lib/cmake/dlib/dlib.cmake.

It most likely is a small issue for most people, since they install and use dlib at the same system. I wanted to package it and came across that problem.

Is it an issue you are aware of or even have decided to do it that way? (out of curiosity)

[xsacha]

Yeah so the problem is that these are full paths rather than just the name of the library file so you can resolve it on the other end.

I suppose the main issue is there is no FindCUDNN or FindMKL.

Workaround is to sed -i 's!/path/to/prebuilts!!g'

[davisking]

I think this is generally how cmake installs work. If you want to propose a change then submit a PR. Note that it must work on all platforms and not break any existing use cases.

[mitsch]

I think I know now why CMake works that way. Using the cmake2 way of setting variables (in the Find* files causes the hardcoded paths. I'm gonna try in the new year to submit a PR where the Find* files are defining target and properties. This I reckon should help to erase the hardcoded paths from the Config*.