Strange commit to FindKDE4Internal.cmake

Pau Garcia i Quiles pgquiles at
Sun Feb 19 22:53:55 UTC 2012

On Sun, Feb 19, 2012 at 11:12 PM, Stephen Kelly <steveire at> wrote:
> Pau Garcia i Quiles wrote:
>> On Sun, Feb 19, 2012 at 5:20 PM, Alexander Neundorf <neundorf at>
>> wrote:
>> Now try and find a LibFooConfig.cmake somehow. Absolutely impossible.
>> Heck, many times headers and libraries will be under some shared
>> network drive! (something like H:\lib + H:\include). Are you going to
>> scan every drive connected to the computer looking for config files?
> How would FindFoo.cmake know where to look?

Exactly like it does know now: trial and error looking for the most
common places. If it does not find the headers, libraries, etc, then
it will report an error and the user will use cmake-gui to browse for
the appropriate files/directories. Windows users are used to this.

If relaying on a LibFooConfig.cmake, find_package will fail saying it
didn't even find LibFooConfig.cmake, which is much worse IMHO.

>> - Libraries (libfoo) must always provide a reference FindLibFoo.cmake
>> in the package and make it available for third party developers in the
>> tarballs. Packages (libfoo-dev) must install this
> Brad on the CMake list suggested that such files would belong in the
> documentation of libfoo (libfoo-doc package), which I thought was an
> interesting point (Or in any other documentation it could be a snippet).

That's what I proposed at the beginning, but in addition to that, I
think it should be added to a /usr/share/cmake/Modules-like directory.
But that place is *only* for official 3rd-party modules, not for, say,
a libpng module provided by KDE.

> If installed with the -dev package (even as a reference implementation or a
> template), it's kind of back to the situation of putting the treasure map
> with the treasure.

I disagree.

Installing FindLibFoo.cmake with the -dev package means you a CMake
module coming from the best possible author: upstream itself. This is
very useful if *you* have installed, say, Wt in a non-standard
directory (for instance: /opt/wt/include and /opt/wt/lib). A very
common use of this is when you are using Qt Commercial on a system
with a KDE desktop: you have (at least) two copies of Qt: the
commercial one and the system one (open source).

> However, if it's part of documentation, presumably the
> person using it will read that documentation and see it.

Pau Garcia i Quiles
(Due to my workload, I may need 10 days to answer)

More information about the Kde-buildsystem mailing list