Strange commit to FindKDE4Internal.cmake

[Pau Garcia i Quiles]

On Sun, Feb 19, 2012 at 5:20 PM, Alexander Neundorf <neundorf at kde.org> wrote:

> CMake searches in a set of self-defined standard locations, as documented in
> the find_package() section of the man page.
> I don't have experience with this myself on Windows, but doesn't this make it
> kind of work ?

No, it does not. On Windows there are absolutely no standards for
anything. Most people will have development libraries and headers
outside path. Several of them. Something like this, for instance:

C:\dev\myproject\3rdparty\include
C:\dev\myproject\3rdparty\lib
C:\kitware\vision\include
C:\kitware\vision\lib
c:\tmp\devellopmentlibraries\msvc2010\libpng\include
c:\tmp\devellopmentlibraries\msvc2010\libpng\lib
...

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?



>> If TheGreatApp does a find_package(LibFoo REQUIRED) this is what happens:
>>
>> - If LibFooConfig.cmake and/or FindLibFoo.cmake is available (either
>> from CMake itself or bundled with my *application* in
>> TheGreatApp/cmake), either LibFoo is found and all goes well, or
>> LibFoo is not found and the error the user will see is "LibFoo not
>> found" because either LibFooConfig.cmake or FindLibFoo.cmake would
>> provide what find_package needs (configuration and/or module).
>>
>> - If LibFooConfig.cmake is installed on Windows but it's on a path
>> CMake does not look into (the *norm* on Windows), or if I do not
>> bundle FindLibFoo.cmake with my application, this is the error a user
>> would see on Windows: an incomprehensible error. Same error as if
>> LibFooConfig.cmake is not available.
>>
>> I cannot see the advantage of LibFooConfig.cmake on non-Unix
>> platforms, or even on Unix platforms when libraries (including
>> FooConfig.cmake) is installed on non-standard locations. It will make
>> find_package fail at the very first step (trying to locate
>> FooConfig.cmake or FindLibFoo.cmake) without even delving into the
>> very finding operation.
>
> We are discussing exactly this currently on the cmake-developers list.
>
> My proposal for cmake 2.8.8 is:
>
> find_package(Qt5)
>
> only uses FindQt5.cmake (and doesn't look for a Qt5Config.cmake), and if
> FindQt5.cmake is not found, it says:
> -----------------------------------------------
> "CMake Error at CMakeLists.txt:7 (find_package):
>  Could not find module FindQt5.cmake.
>
>  Adjust CMAKE_MODULE_PATH to find FindQt5.cmake.
>
>  FindQt5.cmake must either be part of this project itself, in this case
>  adjust CMAKE_MODULE_PATH so that it points to the correct location inside
>  your source tree.
>
>  Or it must be installed by a package which has already been found via
>  find_package().  In this case make sure that this package has indeed been
>  found and adjust CMAKE_MODULE_PATH to contain the location where that
>  package has installed FindQt5.cmake.  This must be a variable provided by
>  that package or something similar, i.e.  for instance not your current
>  CMAKE_INSTALL_PREFIX.  This error in general means that you are relying on
>  a Find-module without ensuring that this Find-module exists."
>
> -----------------------------------------------
>
> OTOH
> find_package(Qt5 NO_MODULE)
> will look only for a Qt5Config.cmake, i.e. you have to enforce Config mode,
> and thus make is possible for cmake to generate better error messages, and so
> for the user to know better what went wrong:
>
> -----------------------------------------------
> "CMake Error at CMakeLists.txt:7 (find_package):
>  Could not find a configuration file for package Qt5 with one of the
>  following names:
>
>    Qt5Config.cmake
>    qt5-config.cmake
>
>  To find the configuration file, set CMAKE_PREFIX_PATH to the installation
>  prefix of Qt5, or set Qt5_DIR to the directory containing a CMake
>  configuration file for Qt5.
> "
> -----------------------------------------------
>
>
> What do you think about this ?

That looks wrong to me.

IMHO:

- find_package must always look for LibFooConfig.cmake before looking
for FindLibFoo.cmake
- Libraries may install a LibFooConfig.cmake. The only advantage in a
LibFooConfig.cmake is it would provide faster discovery for the
"system-wide" libfoo (no need for all the checks, header parsing, etc
that usually takes place in FindLibFoo.cmake)
- Third party applications must always include a FindLibFoo.cmake in
TheGreatApp/cmake and adjust CMAKE_MODULE_PATH conveniently to use it.
- 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 to a place that is
searched for by CMake: some equivalent to
/usr/share/cmake-2.8/Modules, but for *official* 3rd-party
FindLibFoo.cmake modules (i. e. modules provided by the library
itself, not modules written by a third party)

The search order would be like this:

1. LibFooConfig.cmake
2. FindLibFoo.cmake in CMAKE_MODULE_PATH
3. FindLibFoo.cmake in /usr/share/cmake/official3rdpartymodules
4. FindLibFoo.cmake in /usr/share/cmake-2.8/Modules

On Windows, (3) would probably be something like
%CommonProgramFiles%\CMake\official3rdpartymodules

That's a first write-up and I'm probably missing some case but you get the idea.

-- 
Pau Garcia i Quiles
http://www.elpauer.org
(Due to my workload, I may need 10 days to answer)