[cmake-developers] the future of FIND_PACKAGE()

Brad King brad.king at kitware.com
Fri Jun 30 10:09:04 EDT 2006


Alexander Neundorf wrote:
> So I think the FooConfig.cmake files should go under lib/ (since they can be 
> quite specific) and not under share/.

Agreed.

> Leaves the following options:
> 
> lib/Foo/cmake/
> lib/cmake/Foo/
> 
> pkgconfig basically uses the second form. 
> In order to minimize confusion, CMake should IMO support only one of these two 
> locations. It should also define exactly the case to be used: "cmake" vs. 
> "CMake".

I would like to rename the share/CMake directory to 
share/cmake-major.minor (like share/cmake-2.4).  Lower case names are 
more consistent with UNIX style.  That change is independent though and 
can be made separately.

Since there is no lib/(CMake|cmake) directory yet, we are free to 
choose.  Let's go with

   lib/cmake/Foo-1.2/FooConfig.cmake

as the standard place.

> The FIND_PACKAGE() documentation also mentions a version number, maybe this 
> could be used as suffix for the subdir name:
> and with version numbers:
> 
> lib/Foo-x.y.z/cmake/
> lib/cmake/Foo-x.y.z/

Good idea.  If a version number is given we could use it to try to 
narrow the search.  We could look in lib/cmake/Foo-1.2 if no version is 
given or if the version is 1.2.  If the given version is 1.2 then we 
would not look in lib/cmake/Foo-3.4 for example.

> As prefixes I'd suggest to reuse the variables which are used for 
> FIND_LIBRARY(). I think introducing more variables should be avoided, it's 
> hard to remember them. Reusing the ones from FIND_LIBRARY() would also make 
> sense because the FooConfig.cmake files will usually be installed under lib/ 
> directory (where also the library itself will be located).

I'm not sure about this one but I'll tentatively agree.  I'll see how it 
goes during implementation and testing.

> Also the install prefix of cmake itself should be used (i.e. if cmake is 
> installed in a strange location, it will find other stuff installed to the 
> same strange location too).

Good idea.  That way you can have a development prefix with everything 
kept together.

> So, which one should be prefered, FindFoo.cmake or FooConfig.cmake if both can 
> be found by cmake ?
> I'd say FooConfig.cmake, since this is provided by the project and should be 
> more up-to-date/complete/bug fixed/ etc.

If a FindFoo.cmake is in the CMAKE_MODULE_PATH it should be used.  This 
is the means through which a project can override the default 
FIND_PACKAGE behavior.  The FindFoo.cmake script can always simulate the 
new behavior by calling FIND_PACKAGE with the NO_FIND_SCRIPT option to 
look for FooConfig.cmake.  This would also allow FindFoo.cmake to search 
for older versions of Foo that were not built with CMake if desired in 
addition to searching for modern versions.

> How about adding a PATHS argument to FIND_PACKAGE() as there is for all other 
> FIND_XXX() commands ?

Yes, of course.  The idea is to make FIND_PACKAGE determine its 
locations the same way the other FIND_* commands determine theirs.

-Brad



More information about the cmake-developers mailing list