krita CMake module search order wrong

[Alexander Neundorf]

On Friday 22 January 2010, Matthew Woehlke wrote:
> Alexander Neundorf wrote:
> > On Friday 22 January 2010, Cyrille Berger wrote:
> >> On Friday 22 January 2010, Matthew Woehlke wrote:
> >>> I've been unable to build krita for some time, and finally decided to
> >>> investigate closer. Upon inspection, it's not too hard to spot the
> >>> problem:
> >>>
> >>> HAVE_GLEW: '1'
> >>> GLEW_LIBRARIES: ''
> >>>
> >>> On further inspection, it turns out that FindGLEW.cmake (from
> >>> koffice/cmake/modules) isn't even being invoked. Instead it seems to be
> >>> using the FindGLEW.cmake from $KDEDIR/share/apps/cmake/modules.
> >
> > Where does that come from? It's not from kdelibs.
>
> Gluon, I think. At least that's what I recall also using GLEW, and
> there's a FindGLEW.cmake in gluon's cmake/modules. It isn't (presently)
> installed though.

What is Gluon ?

> > I think only kdelibs gives compatibility guarantees, so I wouldn't rely
> > on it being there.
>
> Sure. Actually the point was more that IMO we should be favoring the one
> we (koffice) provide. IOW, assume not only that we need our own copy,
> but that the one in KDEDIR is broken.
>
> >>> I can fix the problem by manually copying the module, but methinks the
> >>> search order is wrong... Thoughts?
> >
> > Set CMAKE_MODULE_PATH so that the koffice module path is prepended to the
> > existing one. I.e. do that after find_package(KDE4).
>
> Not quite. The problem is here:
> macro_optional_find_package(KdepimLibs)
>
> It seems KdepimLibs *prepends* $KDEDIR/share/apps/cmake/modules to
> CMAKE_MODULE_PATH. Despite that it is already present.
>
> I could apply this patch if it is okay:
>
> Index: CMakeLists.txt
> ===================================================================
> --- CMakeLists.txt      (revision 1078300)
> +++ CMakeLists.txt      (working copy)
> @@ -19,7 +19,7 @@
>   set(GENERIC_KOFFICE_LIB_VERSION "6.0.0")
>   set(GENERIC_KOFFICE_LIB_SOVERSION "6")
>
> -set(CMAKE_MODULE_PATH ${CMAKE_SOURCE_DIR}/cmake/modules )
> +set(CMAKE_MODULE_PATH "${CMAKE_SOURCE_DIR}/cmake/modules" )
>
>   #
>   # WARNING: don't change the SHOULD_BUILD_app if an application
> @@ -151,6 +151,7 @@
>   ##
>   macro_optional_find_package(KdepimLibs)
>   macro_log_feature(KDEPIMLIBS_FOUND "KDE PIMLibs" "KDE Personal
> Information Management Libraries" "http://www.kde.org/" FALSE ""
> "Required by KPlato and the KDE address book integration (available as a
> module in KDE)")
> +list(INSERT CMAKE_MODULE_PATH 0 "${CMAKE_SOURCE_DIR}/cmake/modules" )

Or just do once more:
set(CMAKE_MODULE_PATH "${CMAKE_SOURCE_DIR}/cmake/modules" )

>   ##
>   ## Test for boost
> ===================================================================
>
> ...but I wonder if kdepimlibs shouldn't be prepending to CMAKE_MODULE_PATH.

I wonder too.
In general, installing cmake modules is very "costly", in the sense that by 
installing it you actually install a public interface which you (not you, the 
general you) should keep compatible etc.

The same goes for manipulating CMAKE_MODULE_PATH. Now, with the experience we 
have with KDE 4.x, I probably wouldn't manipulate CMAKE_MODULE_PATH again 
hidden in some module :-/

But I think we can't change this anymore, since this could break source 
compatility.

Maybe we could do if somebody requests KDE >= 4.5 or something.

Alex