I've run into a few limitations in find_dependency. I'm not sure if these are by design or could be fixed, so this is really a request for further explanation or design rationale.

The first issue is this:

  if (NOT ${dep}_FOUND)

This seems to be making the assumption that the found variable matches the dependency name, but the case used varies between modules and the name is case sensitive, from my reading of cmake-language. Is this correct? Even if so, should this optimisation be put here rather than in find_package itself? If case sensitivity/naming is an issue, could the _FOUND variable be passed in as an argument, leaving the existing behaviour as the default if unspecified?

The reason for stripping EXACT isn't clear. If my package has a strict requirement on another package, whether the caller has an exact requirement for the version of my package has no bearing on the requirements I have for my dependencies as far as I understand. What's the reason for the existing behaviour?

Support for find_package arguments is limited to the dependency name and optionally the version. I can understand why REQUIRED and related arguments are omitted--that is why find_dependency exists--but I'd quite like to be able to specify COMPONENTS where needed e.g. with FindBoost, and this is not currently possible.

I was wondering if we could perhaps make find_dependency handle and pass through /all/ find_package arguments, minus REQUIRED/QUIET, so that find_dependency can expose the additional functionality offered by find_package. Some may not be useful, in which case they could be omitted, but some like COMPONENTS may be required for the find_package call to be useful.


Regards,
Roger
--

Powered by www.kitware.com

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake-developers

Reply via email to