Strange commit to FindKDE4Internal.cmake

Alexander Neundorf neundorf at
Sun Feb 19 08:49:20 UTC 2012

On Sunday 19 February 2012, Pau Garcia i Quiles wrote:
> 2012/2/18 Maciej Mrozowski <reavertm at>:
> > FindXXX.cmake should not be installed to target system because it
> > suggests this file will be somewhat magically available for the client
> > (application using FindXXX.cmake).
> > But it will not and it's it's client's sole responsibility to provide
> > this file.
> > libfoo can of course provide FindXXX.cmake in its source tarball (in
> > misc/sdk/contrib directory for instance) so that libfoo clients may copy
> > it to their buildsystems, but libfoo should never install this file by
> > itself.
> 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.
Right now, they write it themselves and add it to their project, or search 
whether they can find it anywhere. But putting it in the package is wrong. Or 
maybe it could be put in a place where it is not expected to be found by 
cmake, but where it is expected to be found by the developer, who should then 
copy it into its project (so cmake can find it).

> > 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.


More information about the Kde-buildsystem mailing list