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

[Doug Henry]

I'm trying to follow this thread because it seems like it might be important
to me, but I'm not sure I understand the root problem.  The problem isn't
finding zlib?  The problem isn't using custom modules?  I guess there is
something special about the custom zlib module that cmake's module doesn't
provide?

-thanks


On 10/26/06, Alan W. Irwin <irwin at beluga.phys.uvic.ca> 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 at cmake.org
> http://www.cmake.org/mailman/listinfo/cmake
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://public.kitware.com/pipermail/cmake/attachments/20061027/62e6a205/attachment.html