From kde-buildsystem  Sun Feb 19 15:24:37 2012
From: Alexander Neundorf <neundorf () kde ! org>
Date: Sun, 19 Feb 2012 15:24:37 +0000
To: kde-buildsystem
Subject: Re: Strange commit to FindKDE4Internal.cmake
Message-Id: <201202191624.37990.neundorf () kde ! org>
X-MARC-Message: https://marc.info/?l=kde-buildsystem&m=132966519703173

On Sunday 19 February 2012, Pau Garcia i Quiles wrote:
> >> On Linux/BSD/etc, most people never download or use the source tarball
> >> for libfoo. When they are developing, they would download libfoo-dev.
> >> Where are they going to take FindLibFoo.cmake from if they never used
> >> libfoo.tar.gz in the first place?
> > 
> > In the future from extra-cmake-modules.
> 
> What if the piece of software I'm talking about is not part of KDE?

Try to get it into extra-cmake-modules.
extra-cmake-modules is not in any way KDE specific.
It just happens to be started by KDE developers and hosted on KDE 
infrastructure.

> If I'm the author of libfoo, IMHO it makes a lot of sense to
> distribute a FindLibFoo.cmake in libfoo.tar.gz.
> 
> If I'm the packager of libfoo in, say, Debian, it makes a lot of sense
> to install a reference FindLibFoo.cmake in some place where it is
> easily available for developers which will use libfoo-dev.
> 
> Please note I've never said FindLibFoo.cmake should be installed in
> /usr/lib/cmake-2.8/Modules. For instance, in the the Wt package I
> maintain for Debian, FindWt.cmake will be installed to
> /usr/share/doc/libwt-dev/cmake.

That sounds okish, but developers who use this, should not try to use this 
directly. It is ok for them to copy this file into their project, and use it 
from there.
 
> >> > 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.
> >> 
> >> That's what FooConfig.cmake is for. We are talking about a different
> >> thing here.
> > 
> > No, it's completely related.
> 
> I'd say we are still talking about two different things. This is how I see
> it:
> 
> - FooConfig.cmake is useful to find LibFoo when it is *already*
> *installed* in *this* *system*. It's comparable to .pc files.

Yes.
 
> - A reference FindLibFoo.cmake is useful for developers who want to
> make sure libfoo will be located on *any* platform, be it Linux,
> Windows, Mac or something else. FooConfig.cmake is probably of little
> use on Windows, 

Why do you think that ?

> which is why I, as a developer of TheGreatApp (an
> application based on libfoo) would copy
> /usr/share/doc/libfoo-dev/cmake/FindLibFoo.cmake to TheGreatApp/cmake,
> add TheGreatApp/cmake to CMAKE_MODULE_PATH and use find_package(foo
> REQUIRED). Especially if TheGreatApp is not a KDE application, which
> has no reason to use or know about extra-cmake-modules.

As written above, extra-cmake-modules is not intended to be in any way bound 
to KDE.

Right now, for Qt5 you have to do 

find_package(Qt5 REQUIRED)

Serious question: if you then get the following error message from cmake, what 
do you think is the problem ?

CMake Error at CMakeLists.txt:3 (find_package):
  Could not find module FindQt5.cmake or a configuration file for package
  Qt5.

  Adjust CMAKE_MODULE_PATH to find FindQt5.cmake or set Qt5_DIR to the
  directory containing a CMake configuration file for Qt5.  The file will
  have one of the following names:

    Qt5Config.cmake
    qt5-config.cmake

-- Configuring incomplete, errors occurred!


Alex
_______________________________________________
Kde-buildsystem mailing list
Kde-buildsystem@kde.org
https://mail.kde.org/mailman/listinfo/kde-buildsystem