This is my understanding. Everybody,
please correct me if I am wrong.
There are two types of modules:
<name>Config.cmake. and Find<name>.cmake
A package (eg. library)
provides <name>Config.cmake. The
<name>Config.cmake
advertises package's locations (where were its
headers and libraries installed), version, definitions
(whether to do -D<name>_DLL on
Windows), and anything else related to the usage of this
package.
It is
similar to what <name>.pc is to pkg-config. The '<name>' in this
case is the package's
own
name.
The Find<name>.cmake either
comes with CMake distribution or is created by a
programmer
working on another package. The difference
is that it is a 'seeker' module. It
searches include paths for <name>'s headers,
searches library paths for <name>'s libraries, etc.
Doug, this thread is about a
situation when <name>Config.cmake and
Find<name>.cmake
exist
for the same package. Specifically, the library provides zlibConfig.cmake and
CMake
distribution provides Findzlib.cmake. Now, another
package wants to use zlib so it uses
FIND_PACKAGE(zlib). Before Brad's changes,
CMake would just use Findzlib.cmake which would
render
the zlibConfig.cmake useless. There was no
other way around it.
--
Artur Kedzierski
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Doug Henry
Sent: Friday, October 27, 2006 5:34
To: Alan W. Irwin
Cc: Kedzierski, Artur CIV NAVSURFWARCENDIV CORONA; Brad King; CMake Mailing List
Subject: Re: [CMake] Telling CMake to use zlibConfig.cmake instead of the Findzlib.cmake
-thanks
On 10/26/06, Alan W.
Irwin <[EMAIL PROTECTED]>
wrote:
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
__________________________
_______________________________________________
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
