[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-buildsystem
Subject:    Re: Strange commit to FindKDE4Internal.cmake
From:       Pau Garcia i Quiles <pgquiles () elpauer ! org>
Date:       2012-02-19 21:45:00
Message-ID: CAKcBoktjneiSetewgW-Jmw3oJEa8FO5aZFKrFG8hXKfV9ZMoxg () mail ! gmail ! com
[Download RAW message or body]

On Sun, Feb 19, 2012 at 5:20 PM, Alexander Neundorf <neundorf@kde.org> wrot=
e:

> 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 mak=
e 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):
> =A0Could not find module FindQt5.cmake.
>
> =A0Adjust CMAKE_MODULE_PATH to find FindQt5.cmake.
>
> =A0FindQt5.cmake must either be part of this project itself, in this case
> =A0adjust CMAKE_MODULE_PATH so that it points to the correct location ins=
ide
> =A0your source tree.
>
> =A0Or it must be installed by a package which has already been found via
> =A0find_package(). =A0In this case make sure that this package has indeed=
 been
> =A0found and adjust CMAKE_MODULE_PATH to contain the location where that
> =A0package has installed FindQt5.cmake. =A0This must be a variable provid=
ed by
> =A0that package or something similar, i.e. =A0for instance not your curre=
nt
> =A0CMAKE_INSTALL_PREFIX. =A0This error in general means that you are rely=
ing on
> =A0a 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 mod=
e,
> and thus make is possible for cmake to generate better error messages, an=
d so
> for the user to know better what went wrong:
>
> -----------------------------------------------
> "CMake Error at CMakeLists.txt:7 (find_package):
> =A0Could not find a configuration file for package Qt5 with one of the
> =A0following names:
>
> =A0 =A0Qt5Config.cmake
> =A0 =A0qt5-config.cmake
>
> =A0To find the configuration file, set CMAKE_PREFIX_PATH to the installat=
ion
> =A0prefix of Qt5, or set Qt5_DIR to the directory containing a CMake
> =A0configuration 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)
_______________________________________________
Kde-buildsystem mailing list
Kde-buildsystem@kde.org
https://mail.kde.org/mailman/listinfo/kde-buildsystem
[prev in list] [next in list] [prev in thread] [next in thread]