find_package has different behaviours in config and module options
I am experiencing different behaviours of find_package()
calls, depending from the option it is going to use to obtain result variables. Suppose I am creating a library (A) which depends on other libraries (B and C) and I am building all of them from source on my computer, using CMake to drive the building of all of them.
Let's suppose also that lib B has its own FindLibB.cmake module, while lib C exports a LibC-Config.cmake.
In my library A I will request a find_package(LibB)
and a find_package(LibC)
of course to be able to use them.
But then I see two different behaviours: the LibA_LIBRARY
variable will contain the full path to the library and so the linker is perfectly satisfied for the project itself and also any downstream project, while the LibC_LIBRARY
variable will contain only the name of the library. This will make my library A happy (since CMake will populate the library dir for my project), but will make any downstream project very unhappy because they will be unable to find the library if not instructed to do a find_package(LibC)
(which should be not necessary if the downstream project does not have an explicit dependency on it).
An example: I built OpenCV on Windows, which depends on many libraries, some found through their cmake module file (example: LibLZMA), others through their cmake config file (example: VTK). OpenCV builds without any problem but if I try to use it in a downstream project, the linker complains that it does not know where to find VTK libraries, while it knows perfectly he had to link to LibLZMA which is found because it has the full path. Of course my downstream project is not triggering any find_package(LibLZMA)
nor find_package(VTK)
, just a find_package(OpenCV)
. I could add a find_package(VTK)
in my downstream project too, but I am sure there must be more elegant solutions!
I opened an issue on the OpenCV repository, for them it's a known issue with CMake, but maybe I am just unaware of any best practice here, so please let me know.