Am 19.02.2012 22:45, schrieb Pau Garcia i Quiles:
On Sun, Feb 19, 2012 at 5:20 PM, Alexander Neundorf<[email protected]> 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/Module
cmake 2.8.3 on linux installs it Find... scripts in /usr/share/cmake/modules
cmake 2.8.7 on windows installs it Find... scripts in
<install-root>/share/cmake-2.8/Modules
em On Windows, (3) would probably be something like
%CommonProgramFiles%\CMake\official3rdpartymodules
following this scheme it would be required to add
${CMAKE_INSTALL_PREFIX}/share/cmake/official3rdpartymodule.
KDElibs on windows installs it Find... scripts in
${CMAKE_INSTALL_PREFIX}/share/apps/cmake/modules, should 3rdparty
packages be installed into that dir too ?
Ralf
_______________________________________________
Kde-buildsystem mailing list
[email protected]
https://mail.kde.org/mailman/listinfo/kde-buildsystem
