On Sunday 19 February 2012, Pau Garcia i Quiles wrote: > On Sun, Feb 19, 2012 at 11:41 PM, Ralf Habacker > > <ralf.habac...@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 _______________________________________________ Kde-buildsystem mailing list Kde-buildsystem@kde.org https://mail.kde.org/mailman/listinfo/kde-buildsystem