[PATCH] Port from UsePkgConfig to PkgConfig in kdelibs/cmake/modules

[Alexander Neundorf]

On Thursday 15 April 2010, Friedrich W. H. Kossebau wrote:
> Jeudi, le 15 avril 2010, à 21:41, Alexander Neundorf a écrit:
> > On Thursday 15 April 2010, Friedrich W. H. Kossebau wrote:
> > > Hi,
> > >
> > > messing around with the buildsystem I stumbled upon the message to port
> > > away from UsePkgConfig. Trying to gain more experience with cmake I
> > > produced the attached patches, they seem to work for me.
> >
> > Very cool, thanks a lot :-)
> >
> > > The ones for (K)Exiv2, KDCRaw and Kipi were more complex, did I match
> > > the logic?
> > >
> > > Okay to commit, or to be improved before?
> >
> > If the pkg-config executable hasn't been found, pkg_check_modules() does
> > nothing, right ?
>
> No idea, others like FindLCMS use it without checking if it is really
> found, too. Only FindStrigi seemed to check for that. But I chose the easy
> template ;)

Just rename to pkg-config executable on your system to something else 
temporarily, remove CMakeCache.txt or just use a different build tree and see 
what happens :-)
Everything should still work if CMAKE_PREFIX_PATH is set properly.

(you can just use a separate CMakeLists.txt which only does a 
find_package(KIPI) etc. for that and check the results, no need to always run 
it on a full kde module. If it doesn't find FindKIPI.cmake then, put a 
set(CMAKE_MODULE_PATH <dir_where_FindKIPI.cmake_is>)
in the first line of that separate CMakeLists.txt)

> So that should be approached in another step, if needed.
>
> > FindExiv2.cmake:
> > set(EXIV2_MIN_VERSION "0.12")
> > is only in the NOT WIN32 branch, right ? I think at least the setting of
> > this variable shouldn't be limited to non-Windows.
>
> Was that way before, will move it out of the non-Windows for consistency
> then.
>
> > FindKIPI.cmake: is KIPI_FOUND set here directly after the results from
> > pkg-config, i.e. not by checking the results of the find_path/library()
> > calls ? This should be changed. Can you please also have another look at
> > the other files whether this is the case there ?
>
> The trick, as found in the old code and kept, is with
>       set(KIPI_FOUND PC_KIPI_FOUND)
>       set(KIPI_VERSION_GOOD_FOUND PC_KIPI_FOUND)
> that only on PC_KIPI_FOUND=true the results of find_path/library() are
> checked and KIPI_FOUND is updated to these results. Means it relies on the
> negative result of pkg_check_modules already. If this is acceptable the
> logic seems fine to me.

This should be changed.
If pkg-config is there and brings a good result, this good result should be 
preferred. 
If pkg-config does not exist or pkg-config doesn't find what we are looking 
for, we should still try to find it outselves.

> > Looking Ok:
> > FindGLIB2.cmake
> > FindKdraw.cmake
> > FindKexvi2.cmake
> > FindPopplerQt4.cmake
>
> Good :) So, is the above reasoning fine and can I enter Enter to "svn ci"?

After dealing with the two comments, yes, please :-)

Alex