finding software with cmake

[Matt Rogers]

On Thursday 02 August 2007 21:49, Alexander Neundorf wrote:
> Hi,
>
> I just committed a change to FindKDE4Internal.cmake so that more
> directories are searched by default by the FIND_XXX() commands.
> Now also always the directories in the current install prefix and in the
> install location of the currently running cmake will be searched. This will
> be also the case starting with the next major cmake release, maybe already
> starting with 2.4.8.
>
> Additionally the kde4 install directories are now also searched by default.
>
> So e.g. if you install cmake and e.g. kdesupport stuff (like strigi) to
> $HOME/bin, lib and include and kde4 to $HOME/kde4/bin, lib and include,
> everything in these directories will now be found automatically, e.g.
>
> find_library(STRIGI_STREAMANALYZER_LIBRARY NAMES streamanalyzer)
>
> would in this case work because it would be in $HOME/lib and cmake would be
> in $HOME/bin.
>
> Regarding pkgconfig:
> it is useful, but it has issues.
> -it doesn't exist on all platforms

not true. see http://pkg-config.freedesktop.org/wiki/ where it explicitly 
mentions Mac OS X and Windows.

> -it doesn't work correctly if PKGCONFIG_PATH isn't set up correctly

not always true:
matt at silver ~ $ echo $PKG_CONFIG_PATH

matt at silver ~ $ pkg-config --cflags glib-2.0
-I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include


> -the information for the libraries can be used only as additional hint,
> because cmake should get only libraries with the full path, e.g. libs which
> were found using FIND_LIBRARY(). If e.g. the link flags from pkgconfig are
> simply given to cmake using TARGET_LINK_LIBRARIES() cmake can't check for
> conflicting libraries and so can't sort the link directories correctly.
>
> It is a good thing to use pkgconfig as additional source of information,
> but not more.
>

At least as it relates to CMake. Other build systems will work with pkg-config 
just fine since they don't have the same sort of features that CMake does. :)

> Instead, if even with the changes above some stuff isn't found by the
> FIND_XXX() commands, you can set the CMAKE_INCLUDE_PATH, CMAKE_PROGRAM_PATH
> and  CMAKE_LIBRARY_PATH environment variables to tell cmake about
> additional directories where FIND_XXX() should search.
>

Are these environment variables set in the shell or as arguments to cmake?

> About searching software which has been built with cmake:
> kdelibs install a file KDELibsDependencies.cmake to
> share/apps/cmake/modules/, this will stop one of the next mondays, then the
> file will be installed only as "KDE4Config.cmake" to lib/kde4/cmake/.
> Any software built with cmake can install such a file which contains
> information about itself, e.g. lib dependencies, include dirs, the version,
> compile flags, etc.
> Since these are machine dependent, they should be installed under lib/.
> Software which wants to use that software can then simply include() this
> file in its own cmake files to get all the information (of course the file
> has to be found first...)
>
> In one of the future cmake releases the FIND_PACKAGE() command will support
> these files, if you look at the current documentation for FIND_PACKAGE()
> you will notice that FooConfig.cmake is mentioned, but only under special
> circumstances. This will be extended so it becomes much easier to use
> software built with cmake with other cmake projects.
>
> Bye
> Alex
>
> P.S. did you know about the "edit_cache" and "rebuild_cache" make targets ?
> The first one starts ccmake on the current project, the second one reruns
> cmake on the current project -> easier than typing these commands manually

I did, but I think it's safe to say that I've dug deeper into CMake than most 
KDE developers have. :)
-- 
Matt
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://mail.kde.org/pipermail/kde-core-devel/attachments/20070802/1ffcb65b/attachment.sig>