Strange commit to FindKDE4Internal.cmake

[Pau Garcia i Quiles]

On Sun, Feb 19, 2012 at 11:12 PM, Stephen Kelly <steveire at gmail.com> wrote:
> Pau Garcia i Quiles wrote:
>
>> On Sun, Feb 19, 2012 at 5:20 PM, Alexander Neundorf <neundorf at kde.org>
>> 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)