CMake:Improving Find* Modules: Difference between revisions

From KitwarePublic
Jump to navigationJump to search
No edit summary
(Replace content with link to new CMake community wiki)
(11 intermediate revisions by 5 users not shown)
Line 1: Line 1:
On the CMake mailing list there was a long discussion on how to improve the Find* modules in CMake. Currently (CMake 2.6.2), there are several issues with the Find* modules that cause trouble on some configurations.  See this thread :[]

== Problems with current Find* modules ==
This page has moved [*-Modules here].
* Finding packages in non-standard locations can be difficult and is not standardized across all the Find* modules.
* The parsing and use of pkg-config, and other config tools does not always find the full paths to libraries that are required for the build.
* Often times a Find* module has a key variable that when changed should cause CMake to re-discover many other cached variables.  Currently, there is no uniform way to do this in CMake
* If multiple ABI's exist on a machine, CMake may find a .so or .a library that will not work with the rest of the libraries found or with the compiler and flags picked.
== Proposed solutions to Find* issues ==
*  Each module should have an environment variable that is looked at first, much like the CC and CXX environment variables do for the compiler tool chain discovery.  Once the module finds the package based on the environment variable, a CMake cache variable of the same name should be created.  If the environment variable is present, but the software is NOT found, then the module should stop looking and report the package not found.
* Add ability to parse compile lines like the ones produced from pkg-config and turn them into full paths to libraries. So, turn -L/my/path -lfoo into /my/path/libfoo.a.
* Add an easy way to create dependent cache variables, that when changed unset a number of other variables.  Something like this:
check_cache_depend(VAR1 DVAR1 DVAR2 DVAR3 DVAR4)
If VAR1 changes in the cache from a previous value, then DVAR1, DVAR2, DVAR3, and DVAR4 are all removed from the cache.  You would put something like that at the top of a FindFoo.cmake module.  For Qt it would be:
* For the ABI issue, a try-compile should most likely be used in each Find* module.  However, ideally this would have to be integrated into the find_library command so that it would not find libraries that were of the wrong ABI.  Currently, there is not a good proposal for dealing with this issue.
== Current workarounds  ==

Latest revision as of 15:40, 30 April 2018

The CMake community Wiki has moved to the Kitware GitLab Instance.

This page has moved here.