overriding CMAKE_MODULE_PATH

[Yury G. Kudryashov]

Andreas Pakulat wrote:

> On 16.08.10 00:09:41, Yury G. Kudryashov wrote:
>> Alexander Neundorf wrote:
>> > On Sunday 15 August 2010, Yury G. Kudryashov wrote:
>> >> Many (all?) KDE modules have the following string in the beginning of
>> >> CMakeLists.txt:
>> >>
>> >> set(CMAKE_MODULE_PATH ${CMAKE_SOURCE_DIR}/cmake/modules)
>> >>
>> >> What do you think about replacing this string with the following?
>> >>
>> >> set(CMAKE_MODULE_PATH ${CMAKE_SOURCE_DIR}/cmake/modules
>> >> ${CMAKE_MODULE_PATH})
>> >>
>> >> This would allow user to say, e.g.,
>> >>
>> >> cmake ${kdenetowrk_src_dir} -
>> >> DCMAKE_MODULE_PATH=${libktorrent_prefix}/share/apps/cmake/modules
>> > 
>> > Why would you want to do that ?
>> > I think this shouldn't be necessary, and might break more stuff than it
>> > helps.
>> Because I have libktorrent installed into a different prefix (not
>> CMAKE_INSTALL_PREFIX), and kdenetwork fails to find it.
> 
> Then either specify CMAKE_PREFIX_PATH for fix the FindKTorrent.cmake
> module.
Cmake looks for FindKTorrent in CMAKE_MODULE_PATH, not CMAKE_PREFIX_PATH.

BTW, forcing "external" part of CMAKE_MODULE_PATH to be
map (x: x + "/share/apps/cmake/modules") CMAKE_PREFIX_PATH
is OK to me.

>> What can it break? Why not force CMAKE_PREFIX_PATH if you force
>> CMAKE_MODULE_PATH?
> 
> CMAKE_PREFIX_PATH has other uses than CMAKE_MODULE_PATH, so this
> wouldn't make any sense.
I meant that both can be used to help buildsystem find the dependencies 
installed into non-standard prefixes.
> 
> Andreas
>