CMake:Improving Find* Modules: Difference between revisions

From KitwarePublic
Jump to navigationJump to search
(New page: 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 trou...)
 
No edit summary
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.  
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 :[http://www.cmake.org/pipermail/cmake/2008-November/025131.html]
 


== Problems with current Find* modules ==
== Problems with current Find* modules ==
Line 17: Line 16:




*  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.   See this thread :[http://www.cmake.org/pipermail/cmake/2008-November/025131.html]
*  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 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.

Revision as of 18:06, 10 November 2008

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 :[1]

Problems with current Find* modules

  • 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:

check_cache_depend(QT_QMAKE_EXECUTABLE QT_QTDESIGNERCOMPONENTS_INCLUDE_DIR QT_QTDESIGNERCOMPONENTS_LIBRARY_RELEASE ...)

  • 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