[CMake] Telling CMake to use zlibConfig.cmake instead of the Findzlib.cmake

Alan W. Irwin irwin at beluga.phys.uvic.ca
Thu Oct 26 18:17:11 EDT 2006


On 2006-10-26 14:15-0700 Kedzierski, Artur CIV NAVSURFWARCENDIV CORONA wrote:

> 	Thank You for the suggestion.
> 	Your interpretation is right but there is a catch to it.
> There is another module that gets in the way. The "private
> module designed for one project" is zlibConfig.cmake. CMake
> distribution comes with a module Findzlib.cmake. When
> another project calls FIND_PACKAGE(zlib), CMake searches for Findzlib.cmake
> first.

I think the real problem here is the documentation of FIND_PACKAGE needs
updating.  It currently (version 2.4.3) says,

"Directories listed in CMAKE_MODULE_PATH are searched for files called
"Find<name>.cmake". If such a file is found, it is read and processed by
CMake, and is responsible for finding the package.  If no such file is
found, it is expected that the package is another project built by CMake
that has a "<name>Config.cmake" file."

The meaning of the phrase "another project built by CMake" is not clear.  I
cannot believe that is some arbitrary project somewhere on the net.  Even if
it is is another project built on the same computer by the same user, then
how does CMake find that project in the user's filesystem?  That leaves the
possibility that the documentation is referring to modules distributed
with CMake itself (in $CMAKE_PREFIX/share/CMake/Modules on Linux systems).
But for 2.4.3, there is only one of those (UsePkgConfig.cmake) that has
that name form.

In light of this confusing documentation about the "<name>Config.cmake" form
and almost complete lack of use of that form in the modules distributed with
CMake I suggest you simply ignore that form of name and stick with the name
Findzlib.cmake for your private module.  Of course, that name clashes with
the Findzlib.cmake distributed with CMake in
$CMAKE_PREFIX/share/CMake/Modules, but according to the documentation of
CMAKE_MODULE_PATH that I quoted above, the nameclash should be resolved in
favor of the private version.  I haven't tried this myself, but I am
virtually positive it must work that way. (Why in the world would the user
want the CMake version of the module when they have gone out of their way to
make a private version which they specifically tell cmake how to locate via
CMAKE_MODULE_PATH?)

Anyhow, that is more than enough speculation; I think it is time for you to
try a private version of Findzlib.cmake pointed to by CMAKE_MODULE_PATH to
see whether that works.  I would be most interested in your result.

Alan
__________________________
Alan W. Irwin

Astronomical research affiliation with Department of Physics and Astronomy,
University of Victoria (astrowww.phys.uvic.ca).

Programming affiliations with the FreeEOS equation-of-state implementation
for stellar interiors (freeeos.sf.net); PLplot scientific plotting software
package (plplot.org); the Yorick front-end to PLplot (yplot.sf.net); the
Loads of Linux Links project (loll.sf.net); and the Linux Brochure Project
(lbproject.sf.net).
__________________________

Linux-powered Science
__________________________


More information about the CMake mailing list