Strange commit to FindKDE4Internal.cmake

[Brad King]

On 2/19/2012 5:53 PM, Pau Garcia i Quiles wrote:
> On Sun, Feb 19, 2012 at 11:12 PM, Stephen Kelly<steveire at gmail.com>  wrote:
>> 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.

How is that different?  In the Find module case the user needs to set
FOO_INCLUDE_DIR for foo.h, FOO_LIBRARY for foo.lib, and perhaps others.
In the package Config case the user needs only to set *one* FOO_DIR
value to the location of a single file.

Furthermore the find_package config mode already searches in the common
prefixes for the package configuration file just like the find_library
and find_path commands used in Find modules.  On the CMake dev list
we're currently discussing how to make the error message clearer when
it is not found.  Much of the trouble with it IMO is that it mentions
the Find module case even when searching for a package Config file.

Note that since CMake 2.8.5 we support a package registry:

   http://www.cmake.org/Wiki/CMake/Tutorials/Package_Registry

so packages can be found even if their installers go to a random place
so long as the installers populate the registry.

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

Great, then we agree.

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

I also pointed out in the CMake list thread Stephen mentioned that there
is no reason to even have a Find module for a CMake-aware package except
to tweak find_package's search for the package configuration file
(FooConfig.cmake).  Even then it belongs in the -doc package.

Even if a package upstream does not build with CMake it is still possible
for it to provide a package configuration file for find_package to use,
just like many projects provide pkgconfig .pc files.  Stephen is doing
this for Qt5 AFAIK.

If a package upstream is not CMake-aware then the Find module should be
contributed to CMake upstream.  Otherwise there is no official Find
module available from either CMake or the package upstream so it would
not belong in your proposed official 3rd-party Modules directory anyway.

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

If it comes with the -dev package people think they should find and load
it from there which as Stephen suggested is putting a treasure map with
the treasure.  If it comes with the -doc package then the documentation
can tell them to put it in their project.

> Installing FindLibFoo.cmake with the -dev package means you a CMake
> module coming from the best possible author: upstream itself.

This will still be the case if it comes with the -doc package.

-Brad