Strange commit to FindKDE4Internal.cmake

Maciej Mrozowski reavertm at gmail.com
Sat Feb 18 18:14:02 UTC 2012


On Friday 17 of February 2012 17:48:37 Pau Garcia i Quiles wrote:
> On Fri, Feb 17, 2012 at 5:33 PM, Alexander Neundorf <neundorf at kde.org> 
wrote:
> > A library must never install the Find-module for itself.
> > 
> > This defeats the purpose. This is like putting the remote control right
> > next to the TV, or the treasure map right into the treasure chest. You
> > don't know where the plan is, but once you found the plan, you already
> > found what you are interested in and don't need the plan anymore.
> 
> Let me disagree.
> 
> If I am developing an application which depends on a library, and that
> application may be built on several platforms, I will need a
> FindLibFoo.cmake.
> 
> If libfoo makes FindLibFoo.cmake available (for instance as part of
> the libfoo-dev package), then I only need to copy it to my "cmake"
> directory.
> 
> If libfoo does not make FindLibFoo.cmake available, I will need to go
> and look for it somewhere else: Google it? Look for FindLibFoo.cmake
> at some other project's "cmake" directory?
> 
> It looks like you are recommending the latter. Could you please
> explain why? It does not make sense to me.

FindXXX.cmake should not be installed to target system because it suggests 
this file will be somewhat magically available for the client (application 
using FindXXX.cmake).
But it will not and it's it's client's sole responsibility to provide this 
file.

libfoo can of course provide FindXXX.cmake in its source tarball (in 
misc/sdk/contrib directory for instance) so that libfoo clients may copy it to 
their buildsystems, but libfoo should never install this file by itself.

FindXXX.cmake is not .pc file (pkg-config) equivalent as it doesn't provide 
exact library location in system, just a way to find it.
Like Alex said, it's like a map to find a treasure (exact library location in 
system), and when buried along with a treasure...

-- 
regards
MM
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.kde.org/pipermail/kde-buildsystem/attachments/20120218/1c7756de/attachment.sig>


More information about the Kde-buildsystem mailing list