On Sun, Feb 19, 2012 at 11:12 PM, Stephen Kelly wrote: > Pau Garcia i Quiles wrote: > >> On Sun, Feb 19, 2012 at 5:20 PM, Alexander Neundorf >> wrote: >> 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? >> > > 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. >> - 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 > > 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, but in addition to that, I 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. > 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. Installing FindLibFoo.cmake with the -dev package means you a CMake module coming from the best possible author: upstream itself. This is very useful if *you* have installed, say, Wt in a non-standard directory (for instance: /opt/wt/include and /opt/wt/lib). A very common use of this is when you are using Qt Commercial on a system with a KDE desktop: you have (at least) two copies of Qt: the commercial one and the system one (open source). > However, if it's part of documentation, presumably the > person using it will read that documentation and see it. -- 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