[PATCH] Port from UsePkgConfig to PkgConfig in kdelibs/cmake/modules
Friedrich W. H. Kossebau
kossebau at kde.org
Wed Apr 28 00:54:12 CEST 2010
Mardi, le 27 avril 2010, à 21:30, Alexander Neundorf a écrit:
> On Monday 19 April 2010, Friedrich W. H. Kossebau wrote:
> > Jeudi, le 15 avril 2010, à 22:33, Alexander Neundorf a écrit:
> ...
>
> > > 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.
> >
> > Preferred as in "used in HINTS" or chosen? I decided for the later,
> > because if we use pkg-config we should also trust it's results, no?
>
> No :-)
> We should just use it as a prefered hint.
So what then do with those checks where also the version is considered, like
pkg_check_modules(PC_KEXIV2 QUIET libkexiv2>=${KEXIV2_MIN_VERSION})
?
The old versions also relied on the result of pkg-config, if existing, and did
not do a check of their own, like by grepping for some version string or
compiling.
> > There is just the problem with the(/our?) cmake library handling that we
> > use find_library to get the full path to the library, which pkg-config
> > does not seem to offer, just data about the library suited as flags for
> > compiler and linker.
>
> Exactly, and this is the big issue why I don't really like pkg-config.
Hm, what about filing a request for that to the pkg-config people? :)
> > Any idea how to improve the library stuff to directly take up what
> > pkg-config delivers?
>
> Just use ${PC_LibGLIB2_LIBDIR} as a HINT for FIND_LIBRARY().
>
> Another option would be to add native .pc-file parsing to cmake, so cmake
> can evaluate the pc-files itself, it could also check e.g. in
> CMAKE_PREFIX_PATH/lib/pkg-config/ for the files, etc.
That might be even better. Should then be filed as request to the cmake people
:)
> > So the general pattern (looks like a candidate for a macro) is this, by
> > the example of glib-2.0:
> > --- 8< ---
> > if (NOT WIN32)
> >
> > find_package(PkgConfig)
> > if (PKG_CONFIG_FOUND)
> >
> > pkg_check_modules(PC_LibGLIB2 QUIET glib-2.0)
> >
> > endif (PKG_CONFIG_FOUND)
> >
> > endif(NOT WIN32)
> >
> > if (PC_LibGLIB2_INCLUDEDIR)
> >
> > set(GLIB2_MAIN_INCLUDE_DIR ${PC_LibGLIB2_INCLUDEDIR})
> >
> > else (PC_LibGLIB2_INCLUDEDIR)
> >
> > find_path(GLIB2_MAIN_INCLUDE_DIR NAMES glib.h PATH_SUFFIXES
> > glib-2.0)
> >
> > endif (PC_LibGLIB2_INCLUDEDIR)
> >
> > find_library(GLIB2_LIBRARIES
> >
> > NAMES glib-2.0
> > HINTS ${PC_LibGLIB2_LIBDIR}
> >
> > )
> > --- 8< ---
>
> I think most of the if()'s are not necessary. pkg_check_modules() simply
> does nothing if pkg-config has not been found.
Should be noted in the FindPkgConfig.cmake, then. Attached patch okay?
> Also, even for the case
> that pkg-config reported something, let's better double check.
> Additionally, this way the GLIB2_MAIN_INCLUDE_DIR also ends up in the
> cache, which is good. So I'd prefer something like the following:
>
> find_package(PkgConfig)
> pkg_check_modules(PC_LibGLIB2 QUIET glib-2.0)
>
> find_path(GLIB2_MAIN_INCLUDE_DIR NAMES glib.h
> HINTS ${PC_LibGLIB2_INCLUDEDIR}
> PATH_SUFFIXES glib-2.0)
> find_library(GLIB2_LIBRARIES
> NAMES glib-2.0
> HINTS ${PC_LibGLIB2_LIBDIR} )
>
> Now that I copied it here... the variable above shouldn't be named
> GLIB2_LIBRARIES (plural), but only GLIB2_LIBRARY or GLIB2_GLIB_LIBRARY,
> since it is only one library.
> At the end, GLIB2_LIBRARIES should be set to all libs which are needed when
> linking against GLIB2 (even if it is only one then).
Okay. Integrated your comments into FindGLIB2.cmake FindPopplerQt4.cmake and
finally commited the changes for these two cmake files.
But what do you think should be done for those with an additional version
check?
Cheers
Friedrich
--
KDE Okteta - a simple hex editor - http://utils.kde.org/projects/okteta
-------------- next part --------------
A non-text attachment was scrubbed...
Name: FindPkgConfig.patch
Type: text/x-patch
Size: 575 bytes
Desc: not available
Url : http://mail.kde.org/pipermail/kde-buildsystem/attachments/20100428/6d030669/attachment.patch
More information about the Kde-buildsystem
mailing list