[cmake-developers] the future of FIND_PACKAGE()

[Brad King]

Alexander Neundorf wrote:
> FindFoo.cmake vs. FooConfig.cmake files
> 
> FindFoo.cmake files are generic (and I personally think I like them more). So 
> being generic means they should be installed somewhere under share/ and not 
> under lib/ (according to the file system hier. standard).
> 
> FooConfig.cmake files are not generic and as such shouldn't be installed 
> somewhere under lib/ and not under share/.
> The cmake module directory is located under share/, so it doesn't fit very 
> well for FooConfig.cmake files.
> So the location for FooConfig.cmake files should go either to 
> INSTALL_PREFIX/lib/Foo/cmake/ or CMAKE_ROOT/Configs/.
> The FooConfig.cmake files can probably not be transferred to another 
> installation, since they contain the fixed paths, while FindFoo.cmake files 
> can be copied.

This problem is simpler than you present.  In order for CMake and Foo to 
be used together they need to be connected in some way.  There are a few 
ways for this to happen:

1.) CMake comes with a FindFoo.cmake.  This disucssion is about how to 
remove this need.  Even with the file there may be places Foo is 
installed that it cannot find (like ~/my/hidden/out-of-the-way/dir).

Having ruled out #1 then somehow CMake has to load a file that is 
provided by Foo's installation.  Once CMake has found such a file then 
it knows *exactly* where the rest of Foo is located because this file 
can tell it...there is no "find" involved anymore.  Therefore the name 
FindFoo.cmake is not appropriate for this file...which leaves 
FooConfig.cmake.  Now, on to the location of this file.

2.) When Foo is installed it finds CMake and puts a file in its 
installation.  This puts the burden of finding CMake on every package 
that is built or installed (no simple tarballs allowed).  When a new 
CMake is installed it may not have a copy of the file and will not be 
able to find Foo.  Multiple installations of Foo may overwrite each 
other's CMake-delivery files unless special care is taken.

3.) When Foo is installed it puts a file in some central place that all 
CMakes know to look.  Again this has problems with tarballs and multiple 
versions of Foo.  It is also a step towards requiring third-party 
modules just to run CMake on a project which we definately do not want.

One of my primary requirements for this design is that Foo should be 
able to come as a tarball or zip file.  No full paths and no 
post-install scripts are allowed.  There should be no burden on Foo to 
find anything.  This absolutely rules out #2 and #3.

4.) When CMake runs it searches for a file from Foo's installation.

After discarding #1 CMake cannot have any special knowledge about fancy 
install locations.  Even with it there would always be places Foo could 
hide (like ~/my/hidden/out-of-the-way/dir) that require user 
intervention.  Despite this we can still find Foo 99% of the time.

FIND_PACKAGE(Foo) does have one bit of Foo-specific information: the 
name "Foo".  This is enough to narrow a search quite rapidly from a 
whole directory listing.  If Foo installs the file FooConfig.cmake in a 
stanard place beneath its installation prefix (like 
lib/Foo-1.2/cmake/FooConfig.cmake) then all that remains is for CMake to 
know how to find the installation prefix.

On UNIX, the prefixes

/
/usr
/usr/local
/opt/*

will cover most system installations for most distributions.  If a 
sysadmin or distro adds more prefixes it can put them in a 
CMAKE_PREFIX_PATH environment variable in /etc/profile for all users to 
see.  Similarly if users prefixes in their home directories they are 
responsible for putting the prefix in CMAKE_PREFIX_PATH just like 
~/myroot/bin would have to be put in PATH or ~/myroot/lib in 
LD_LIBRARY_PATH.  We could also consider guessing prefixes from PATH and 
LD_LIBRARY_PATH environment varibles.

On Windows, %ProgramFiles% and the system registry may provide a 
sufficient set of prefixes.

Anyway the point is that CMake should be able to find Foo without Foo 
finding CMake.

-Brad