KF5 Update Meeting Minutes 2013-w31

[Kevin Ottens]

Hello,

On Wednesday 31 July 2013 12:37:52 Stephen Kelly wrote:
> Kevin Ottens wrote:
> > Once the splitting will be done I'm not so sure it's better than using
> > directly the namespaced target names. The reason being that variables are
> > really a pain with cmake... I mean if you mistakenly use a variable name
> > which doesn't exist it's just expanded to nothing. Target names don't have
> > that problem.
> 
> For example:
> 
>  cmake_minimum_required(VERSION 2.8)
>  project(foo)
>  add_executable(someexe main.cpp)
>  target_link_libraries(someexe ${Qt5Core_LIBRARIES})
> 
> 
> CMake runs without failure.
> 
> Change it to
> 
>  target_link_libraries(someexe Qt5::Core)
> 
> and CMake 2.8.13 will recognise the double colons as signifying an IMPORTED
> target:
> 
>  stephen at hal:~/dev/src/playground/cmake/build{master}$ cmake ..
>  -- The C compiler identification is GNU 4.7.3
>  -- The CXX compiler identification is GNU 4.7.3
>  -- Check for working C compiler: /usr/lib/icecc/bin/cc
>  -- Check for working C compiler: /usr/lib/icecc/bin/cc -- works
>  -- Detecting C compiler ABI info
>  -- Detecting C compiler ABI info - done
>  -- Check for working CXX compiler: /usr/lib/icecc/bin/c++
>  -- Check for working CXX compiler: /usr/lib/icecc/bin/c++ -- works
>  -- Detecting CXX compiler ABI info
>  -- Detecting CXX compiler ABI info - done
>  -- Configuring done
>  CMake Error at CMakeLists.txt:21 (add_executable):
>    Target "foo" links to IMPORTED target "Qt5::Core" but the IMPORTED target
> was not found.  Perhaps a find_package() call is missing?

Yes, exactly why I find the targets superior in the long run.
 
> >> target_link_libraries(foo ${KCoreAddons_LIBRARY_TARGETS} )
> >> will guarantee that this thing contains targets, and that these targets
> >> <snip>
> > 
> > Or you could actually explain what's needed for us to make it proper, so
> > that someone like Benjamin can look into it. I'd rather see more team work
> > in the CMake area than it currently is...
> 
> The problem is that external users of frameworks (including other
> frameworks) would use namespaced target names. Eg, KAuth would do this:
> 
>  find_package(KCoreAddons REQUIRED)
>  target_link_libraries(KAuth KF5::KCoreAddons)
> 
> However, as KAuth and KCoreAddons are part of the same buildsystem,
> 'KF5::KCoreAddons' is not defined, but 'KCoreAddons' is. The variable
> abstracts that away, but it is indeed a temporary measure until the repo
> split.
> 
> Another solution, coming in 2.8.13 is ALIAS targets:
> 
>  add_library(KCoreAddons ...)
>  add_library(KF5::KCoreAddons ALIAS KCoreAddons)
> 
>  # Works even in same buildsystem
>  target_link_libraries(KAuth KF5::KCoreAddons)
> 
> So, if this target/variable task is deferred until CMake 2.8.13 can be used,
> the variables don't have to be used even in an intermediate state.

I see, but when is 2.8.13 supposed to be released? I'd rather have us move 
forward.

> >> * using cmake withint KDE frameworks
> > 
> > The most pressing at the moment is the later. The other parts are
> > important of course, but the part about using cmake within KDE Frameworks
> > is badly needed already.
> 
> Any idea what is missing? Or what is the problem that makes it needed so
> badly?

The problem is that we have inconsistencies all over the place, and people 
wondering what to write, how and where... And that's a today problem. I'd like 
to have a mean for people to learn and fix it themselves as they go instead of 
relying only on you and Alex as you're both randomly available (which is fine 
in itself, but means we need the doc mentioned above). Please teach us to 
fish...

Regards.
-- 
Kévin Ottens, http://ervin.ipsquad.net

KDAB - proud supporter of KDE, http://www.kdab.com
-------------- 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-core-devel/attachments/20130731/93f53537/attachment.sig>