[Kde-pim] KDE/kdelibs/cmake/modules

[Alexander Neundorf]

On Wednesday 03 December 2008, Ben Cooksley wrote:
> SVN commit 891837 by bcooksley:
>
> Fix finding of pimlibs to search in KDE4_INCLUDE_DIR first. This will allow
> those who do not install trunk to /usr to build again CCMAIL:
> kdepim at kde.org
> CCMAIL: winter at kde.org
>
>  M  +2 -2      FindKdepimLibs.cmake
>
>
> --- trunk/KDE/kdelibs/cmake/modules/FindKdepimLibs.cmake #891836:891837
> @@ -40,8 +40,8 @@
>    endif (KDEPIMLIBS_DIR)
>  endif (WIN32)
>
> -find_path( KDEPIMLIBS_INCLUDE_DIR kcal/kcal_export.h
> -  ${KDE4_INCLUDE_DIR}
> +find_path( KDEPIMLIBS_INCLUDE_DIR NAMES kcal/kcal_export.h
> +  HINTS ${KDE4_INCLUDE_DIR}
>  )

That patch is ok, but I should comment on it to make clear what happens:

the "old" version of FindKdepimLibs.cmake also did just a 

find_path( KDEPIMLIBS_INCLUDE_DIR kcal/kcal_export.h
          ${KDE4_INCLUDE_DIR} )

I didn't change that.
So both the "old" and "my" version from yesterday brought the same results for 
that.
If "my" version found a wrong kcal_export.h, then also the "old" version found 
the same kcal_export.h, which should have also been already wrong.
What my patch changed is how the KdepimLibsDependencies/Information.cmake file 
is loaded. The "old" version just did 

include(KDEPimLibsDependencies)

which relies on CMAKE_MODULE_PATH being set correctly (which can then point to 
a KDEPimLibsDependencies.cmake file in a different location than the 
kcal_export.h found above.
"My" version explictely loads the KDEPimLibsInformation.cmake file from the 
same install prefix as the header found above, which should be better.
So I suspect that change basically just exposed an existing problem.

Adding the HINTS keyword is a good thing. Still it only helps in finding it 
more often, it doesn't _always_ help.
I have (almost) all KDE modules installed to different prefixes, i.e. 
kdesupport in /opt/kdesupport, kdelibs in /opt/kdelibs, kdepimlibs 
in /opt/kdepimlibs, kdepim in /opt/kde4.
Here KDE4_INCLUDE_DIR would point to /opt/kdelibs (since it's the include 
directory of the KDE4 libraries), so in this case it wouldn't find 
kcal_export.h.

What I do and what I suggest if you also install different parts of KDE to 
different locations, is to use the CMAKE_PREFIX_PATH environment variable.
This is a list of locations where cmake will search first, for all 
find_program(), find_path(), find_file() and find_library() calls.

So I did here:
$ export 
CMAKE_PREFIX_PATH=/opt/qt-copy:/opt/kdesupport:/opt/kdelibs:/opt/kdepimlibs

and this way cmake finds the stuff from these modules first before it checks 
all default locations.
(by also having qt-copy in that variable I don't have to adjust PATH to point 
to the correct qmake).

I hope this helps to clear things up a bit.

There was one more change I did:
FindKdepimLibs.cmake also added KDEPIMLIBS_INCLUDE_DIR to KDE4_INCLUDES. This 
is (was) wrong. A module shouldn't change variables set by other modules 
(side effect). Especially if it adds something to the include dir I didn't 
ask for. So I removed that.
While this is a source incompatible change (packages which relied on that 
without knowing), it is IMO clearly a bug fix, so it was broken and is 
correct now, if something doesn't work anymore it was working only by 
accident (it also wasn't documented). Also that problem hits only 
installations where kdepimlibs is actually installed to a different location 
than kdelibs, which is probably a minority.
I went through all (except kdebindings, kdewebdev, extragear, review and 
playground) other modules and checked they are still working (or fixed 
appropriately by adding KDEPIMLIBS_INCLUDE_DIR).

FindKdepimLibs.cmake now also sets KDEPIMLIBS_FOO_(LIBRAR|LIBS) variables and 
documents this also. The KDE4_ version are also still set (for 
compatibility), but I would strongly suggest to use the variables with the 
KDEPIMLIBS_ prefix instead from now on.
This makes clear
a) where the variable comes from, in case somebody is looking for how it is 
set
b) that it is a library from kdepimlibs and not from kdelibs, so dependencies 
are clearer (yesterday I had actually no chance to find only be searching the 
CMakeLists.txt files which other programs use kdepimlibs, because they 
neither used KDEPIMLIBS_INCLUDE_DIR nor had the library variables a 
distinguishable prefix).

So, please use the KDEPIMLIBS_FOO_(LIBRARY|LIBS) variables from now on.

Alex
_______________________________________________
KDE PIM mailing list kde-pim at kde.org
https://mail.kde.org/mailman/listinfo/kde-pim
KDE PIM home page at http://pim.kde.org/