[Cmake] Find & Use Modules in CMake

Ken Martin ken.martin at kitware.com
Fri Oct 4 11:35:14 EDT 2002


Hey Folk,

 

After a bit of discussion we have come up with an idea for a little more
standardization of the Find Use Modules in CMake. This is a followup to
the nice cleanup that (Ian & Brad) have already been done. Specifically
I'm looking to make sure we have a design that will work long into the
future with both CMake projects and non CMake projects. (plus projects
that currently are not CMake projects but may become CMake projects) The
basic idea Bill, Brad, & I came to is as follows:

 

1. FindFoo.cmake will find FOO and set variables that will go into the
cache that the user can adjust. (pretty much as it currently is except
for FindVTK)

 

2. Other variables that FindFoo defines should not go into the cache if
they will always be relative to cached variables. (a few too many
variables may be cached right now, but otherwise this is the current
situation as well)

 

3. In the case where a project may require multiple settings by the
user, these must be cached (so the user can adjust them). They should
still have reasonable initial values.

 

4. For a larger project that may have many settings that are cached (say
more than 3) There should be a master cache value say FOO_ROOT. If the
user changes FOO_ROOT the other cached values should change as well
(currently this can't be done in CMake but we will add that capability)
Here is a use case for this. A library BAR has four components that are
typically installed relative to each other but can occasionally be
placed elsewhere. If these four values were always relative to each
other only one would be cached and the other three would be computed
from the cached value.  But since that is not the case, all four are
cached. A BAR_ROOT is cached that specified the path to BAR. Whenever
BAR_ROOT is changed the other cached values also will reset to the
relative paths to BAR_ROOT. That way users can easily switch between
multiple installations of a complex project without having to edit many
cache entries each time. This will require a modification to the SET
command so that CACHE values can be modified from a CMakeList file. If
the user has parts of BAR in unusual places then they will have to
modify the other cache values after changing BAR_ROOT.  

 

5. For projects that are built using CMake the FindFOO.cmake code should
locate the FOO_ROOT and then include the FOO_ROOT/FindFOOImpl.cmake (or
something like that, ideas for the name of the file?)

 

6. FindFOO.cmake modules are welcome to set a variable USE_FOO_FILE that
points to a UseFOO.cmake file. The UseFOO.cmake file can set the
LINK_DIRECTORIES and LINK_LIBRARIES and ADD_DEFINITIONS. For smaller
projects there isn't really a need for a UseFOO.cmake file. But for
large projects this can make using the project a little easier.

 

7. LOAD_CACHE should be avoided. It is a tricky command.

 

8. For large CMake projects the FindFOO.cmake file should include all
the libraries required (e.g. the dependencies should be there as well)
We will add a command in CMake to get a list of dependent libraries for
a given library. That way the information doesn't have to be hand
specified in the FIndFOOImpl.cmake file (I'm worried about them getting
out of date). So FIndFOOImpl.cmake will be a configured file.

 

Comments?

 

Ken Martin, PhD

Kitware Inc.

518 371 3971 x101

469 Clifton Corporate Pkwy

Clifton Park NY 12065

 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/cmake/attachments/20021004/b36af94f/attachment.html>


More information about the CMake mailing list