Strange commit to FindKDE4Internal.cmake

Stephen Kelly steveire at
Sun Feb 19 14:25:38 UTC 2012

Pau Garcia i Quiles wrote:

>>> On Linux/BSD/etc, most people never download or use the source tarball
>>> for libfoo. When they are developing, they would download libfoo-dev.
>>> Where are they going to take FindLibFoo.cmake from if they never used
>>> libfoo.tar.gz in the first place?
>> In the future from extra-cmake-modules.
> What if the piece of software I'm talking about is not part of KDE?
> If I'm the author of libfoo, IMHO it makes a lot of sense to
> distribute a FindLibFoo.cmake in libfoo.tar.gz.
> If I'm the packager of libfoo in, say, Debian, it makes a lot of sense
> to install a reference FindLibFoo.cmake in some place where it is
> easily available for developers which will use libfoo-dev.

I'm not sure I follow the logic here.

If libfoo has a CMake based build system, why would the developer not 
install FooConfig.cmake instead?

If libfoo is not using a CMake based buildsystem, but the developer 
recognises that it's relevant, the developer can still create and install 
FooConfig.cmake. See Qt5 which does exactly that (I implemented it).

if libfoo is not using a CMake based buildsystem, and the developer does not 
recognise the relevance of CMake to his downstreams, why would he create and 
install a FindFoo.cmake file?

> Please note I've never said FindLibFoo.cmake should be installed in
> /usr/lib/cmake-2.8/Modules. For instance, in the the Wt package I
> maintain for Debian, FindWt.cmake will be installed to
> /usr/share/doc/libwt-dev/cmake.
>>> > FindXXX.cmake is not .pc file (pkg-config) equivalent as it doesn't
>>> > provide exact library location in system, just a way to find it.
>>> That's what FooConfig.cmake is for. We are talking about a different
>>> thing here.
>> No, it's completely related.
> I'd say we are still talking about two different things. This is how I see
> it:
> - FooConfig.cmake is useful to find LibFoo when it is *already*
> *installed* in *this* *system*. It's comparable to .pc files.
> - A reference FindLibFoo.cmake is useful for developers who want to
> make sure libfoo will be located on *any* platform, be it Linux,
> Windows, Mac or something else. 

Why are you making a distinction between linux, Windows and Mac? What 
difference does that make regarding config files?

> FooConfig.cmake is probably of little
> use on Windows, 

Why is it of little use?

> which is why I, as a developer of TheGreatApp (an
> application based on libfoo) would copy
> /usr/share/doc/libfoo-dev/cmake/FindLibFoo.cmake to TheGreatApp/cmake,
> add TheGreatApp/cmake to CMAKE_MODULE_PATH and use find_package(foo
> Especially if TheGreatApp is not a KDE application, which
> has no reason to use or know about extra-cmake-modules.

If you use config files, then ecm doesn't enter the picture. 

I must be missing something though regarding why config files don't work.



More information about the Kde-buildsystem mailing list