overriding CMAKE_MODULE_PATH

[Andreas Pakulat]

On 16.08.10 01:23:50, Michael Jansen wrote:
> >>> Then either specify CMAKE_PREFIX_PATH for fix the FindKTorrent.cmake
> >>> module.
> >> Cmake looks for FindKTorrent in CMAKE_MODULE_PATH, not CMAKE_PREFIX_PATH.
> > 
> > Right. So where is the problem? FindKTorrent.cmake should either be part
> > of cmake itself, part of kdelibs or be part of kdenetwork. Anything else
> > is a bug (ktorrent shouldn't install a FindKTorrent.cmake that doesn't
> > make any sense). As far as I can neither of the three is a case, so I
> > suggest to add a proper FindKTorrent.cmake to kdenetwork/cmake/modules/.
> > Then you can use CMAKE_PREFIX_PATH to help that Find-Module find
> > ktorrent.
> 
> But we need the CMAKE_PREFIX_PATH -> CMAKE_MODULE_PATH anyway if you ask
> me. It's what i would expect anyway and it would help preventing
> problems like the one described below.
>
> I tried to post the following message to the cmake list but i am pretty
> unable to get an email there.

Did you contact kitware, or is this a 'your' problem?

> I initially thought the FindXYZ.cmake approach (called "Module" mode in
> the documentation was dead after reading about the "Config" mode. Hey i
> thought. That's great. Just install appropriate
> <lower-case-name>-config.cmake" files in an appropriate place and be
> done with it.
> 
> Then i read "Much of the interface is provided for completeness and for
> use internally by find-modules loaded by Module mode.". Then i was
> confused, did some testing and now i see some problems.

I believe the idea of Module vs. Config mode is to leave the 'logic' of
finding the libs and headers properly to the actual library project. So
this part isn't duplicated when each project using the lib provides a
FindLibrary.cmake (until its included in cmake itself). At the same time
FindXXX.cmake is considered useful because it allows to produce nicer
error messages than using the config mode 'standalone'.

> 1. kdelibs provides a FindQJson.cmake module. This will be used if i do
> "find_package(QJson)". It uses pkgconfig to find qjson.
> 
> 2. qjson provides a FindQJSON.cmake module. This will be used if i do
> "find_package(QJSON).  It uses pkgconfig to find qjson.
> 
> So 1. and 2. will most likely find the same and working version of qjson.
> Given a correct PKG_CONFIG_PATH variable it will only return a working
> qjson package in regard to 64/32 bit. Exactly what i want.
>
> 3. qjson installs two file called qjson-config-version.cmake and qjson-
> config.cmake.
> 
> But these two files will be found if anyone use a
> find_package(QjSon|qjson|or any other
> upper/lowercase combination not matching 1 or 2) because of this part of
> cmake behaviour:
> 
> The command searches for a file called "<name>Config.cmake" or
> "<lower-case-name>-config.cmake" for each name specified.
> 
> [...]
> 
> CMake constructs a set of possible installation prefixes for the
> package. Under each prefix several directories are searched for a
> configuration file. The tables below show the directories searched.
> Each entry is meant for installation trees following Windows (W), UNIX
> (U), or Apple (A) conventions.
> 
>   <prefix>/                                                 (W)
>   <prefix>/(cmake|CMake)/                                 (W)
>   <prefix>/<name>*/                                       (W)
>   <prefix>/<name>*/(cmake|CMake)/                         (W)
>   <prefix>/(share|lib)/cmake/<name>*/                     (U)
>   <prefix>/(share|lib)/<name>*/                           (U)
>   <prefix>/(share|lib)/<name>*/(cmake|CMake)/             (U)
> 
> What is not mentioned here that it looks in lib64 (If
> FIND_LIBRARY_USE_LIB64_PATH is set) to. The lib64 is optional, the lib
> not. On OpenSuse here lib64 is for 64bit and lib
> for 32bit. So even if i develop 64bit Software i can't make cmake ignore
> lib/. Whatever it finds there won't suit me. That's why we probably need
> a FindQJson.cmake file. To only search in
> appropriate places for Config Files.

I thought distro's have switched to lib/ for 64 and 32 bit (depending on
which is the system-arch) and lib32 for the 32-bit compat libs in a
64bit System... Anyway, the above is something you should be taking to
cmake people, obviously lib64 should be searched first if the compiler
is 64bit. As far as I can see the problematic case would be having
development-stuff installed for the 32bit version of qjson and no 64bit
version or having both and the 32bit version is found and I wonder how
realistic that is (I don't think its possible on Debian at least,
because only some basic libs are provided as 32bit version on a 64 bit
install).

> And now to the problem. A find_package( qjson ) will work for some and
> not for others. And that is the same for all packages using the all
> lowercase name for their config.cmake files.
>
> If i am right i would consider the all lowercase names harmful.

Yes in that its much more forgiving than the camel-case stuff when it
comes to people being sloppy with their find_package call (or doing
mistakes). Nonetheless if the FindQJson.cmake module is only a thin
wrapper around the config-mode version to give some nice messages all
people still will get the same behaviour. Trouble only starts if the
find-module starts to try to do some magic with prefix-path etc. 

> A project like QJSON that tries to install a FindQJSON.cmake (however
> useful that is) misleads it's users therefore. They perhaps only set
> CMAKE_PREFIX_PATH, add a find_package(QJSON) and run cmake.

That would be the error, they shouldn't set CMAKE_PREFIX_PATH in the
first place, that variable is _purely_ meant for users to set during
cmake-invocation or in the cache.

> It works. Sometimes. But only using the config mode. Because they
> would have to set CMAKE_MODULE_PATH too. And only as long as they
> don't install some 32-bit development version of qjson.

See above, I wonder how realistic it is to have 32-bit development stuff
on a 64bit System in the system prefix. 

> This is all probably a theoritical problem with not much practical
> relevance but i thought i would inquire anyway.

Exactly, so lets keep to practical problems like the one this thread is
about.

Andreas

-- 
Your motives for doing whatever good deed you may have in mind will be
misinterpreted by somebody.