Strange commit to FindKDE4Internal.cmake

[Alexander Neundorf]

On Sunday 19 February 2012, Pau Garcia i Quiles wrote:
> On Sun, Feb 19, 2012 at 11:41 PM, Ralf Habacker
> 
> <ralf.habacker at googlemail.com> wrote:
> > There is a linux rpm package installing about 150 Find... scripts into
> > /usr/share/cmake-2.8/modules  (the package is named cmake) and a 3rdparty
> > library rpm package installing a dedicated Find... script into the same
> > location (or a well known 3rdparty location) because the related Find.
> > script is not in the cmake binary package ? Is this forbidden ?
> 
> On Debian, this is considered a bug. Really.
> 
> > Is the library package maintainer be forced to add his Find<lib>...
> > script to the official cmake release or to a dedicated
> > extra-cmake-find-script-repository and tell the user to install an
> > additional dependency ?
> 
> The library package maintainer must only add this Find<lib>... to the
> library package. He needs not write anything new or look for
> Find<lib>... anywhere else. If the original source tarball (i. e.
> upstream) includes Find<lib>..., then it will be installed in
> /usr/share/doc/libfoo-dev/cmake.
> 
> > And when his Find... script is not accepted by the
> > cmake maintainers for whatever reasons,
> 
> I never mentioned this Find... script would ever be submitted to CMake
> maintainers. It should not.

Well, that's what we are doing since kdelibs 4.0 and it works very well for 
us.
CMake ships a very small FindKDE4.cmake, which searches for our lengthy 
FindKDE4Internal.cmake, which when found, does the rest.
The FindKDE4Internal.cmake is quite similar to a KDE4Config.cmake file, but 
this mechanism didn't exist yet back then, I think it was added in 2.6.0.

So, in general, yes, upstreaming a Find-module to cmake is a good thing.

The whole idea of the Config.cmake files is more or less to get rid of Find-
modules, to get rid of the need to have a lot of information about Foo outside 
Foo (because Foo provides all the information in its config file).


While I understand the idea behind your suggestion to first search for 
Config.cmake files, and if not found, fall back to Find-module, this doesn't 
improve the situation in the error case, and also it shouldn't be necessary.


If a package installs a config file, you should (IMO) call find_package with 
the NO_MODULE parameter:

find_package(Foo NO_MODULE).

If you think this is not good enough for finding it, you can add additional 
paths where to look:

find_package(Foo NO_MODULE PATHS /opt/kde4 c:/mystuff )

If you think this shouldn't be in a users CMakeLists.txt, but in a Find-
module, I agree.

Then the CMakeLists.txt would be:

find_package(Foo)

and FindFoo.cmake would be:

find_package(Foo NO_MODULE PATHS /opt/kde4 c:/mystuff )
find_package_handle_standard_args(Foo CONFIG_MODE)

which is basically trivial and additional gives a nice and brief error/success 
message thanks to fphsa()

From the two error messages I posted earlier, the one which talks about the 
missing Find-module, is directed at the developers of the package. It could be 
reworded less lengthy and less friendly:

"Could not find FindFoo.cmake

Your buildsystem is broken, fix it !"

No user should ever see this.

Users should only see:

"Could not find FooConfig.cmake file.
Adjust CMAKE_PREFIX_PATH to find it".


or the brief summary from find_package_handle_standard_args():

"Found Foo (/usr/lib/cmake/FooConfig.cmake)"
OR
"Did not find Foo (neither FooConfig.cmake nor foo-config.cmake)"
OR the normal messages:
"Found Foo (/usr/lib/libfoo.so)"


Alex