From kde-buildsystem Mon Feb 20 15:47:01 2012 From: Brad King Date: Mon, 20 Feb 2012 15:47:01 +0000 To: kde-buildsystem Subject: Re: Strange commit to FindKDE4Internal.cmake Message-Id: <4F426AF5.5020707 () kitware ! com> X-MARC-Message: https://marc.info/?l=kde-buildsystem&m=132975285825742 On 2/19/2012 5:53 PM, Pau Garcia i Quiles wrote: > On Sun, Feb 19, 2012 at 11:12 PM, Stephen Kelly 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 _______________________________________________ Kde-buildsystem mailing list Kde-buildsystem@kde.org https://mail.kde.org/mailman/listinfo/kde-buildsystem