KF5 Update Meeting Minutes 2013-w31

Wed Aug 21 06:34:12 UTC 2013

On Tuesday 20 August 2013 22:31:28 Alexander Neundorf wrote:
> On Wednesday 31 July 2013, Kevin Ottens wrote:
> > 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.
> 
> ... and has been since months.

Yep...

> And I'd like to get that fixed rather sooner than later, and I have plan how
> to do that.
> I can hardly follow all the new (cool) features in cmake, and I guess
> everybody else (except Steve) even less.
> I'm still willing to put in the work into kdelibs, but this won't last much
> longer if I have to discuss that every week again.

Well, maybe that gets discussed every week in part because of 
misunderstandings then. As you point out you can hardly follow all the new 
cool features... and the contention point of the targets is one such new 
feature.

> Doesn't feel like much fun to spend my spare time this way.

Like for everybody's time on that aspect to be honest. It just scares people 
off and I'd rather have the number of people touching our cmake files grow 
rather than shrink. Also if we want it to grow it can't be your decisions 
alone anymore.

> I don't see the need for adding aliases to cmake:
>   add_library(KCoreAddons ...)
>   add_library(KF5::KCoreAddons ALIAS KCoreAddons)

I do...

> There is nothing wrong with:
> CMakeLists.txt (in-project):
>   set(KCoreAddons_LIBRARY_TARGETS KCoreAddons)
> and KCoreAddonsConfig.cmake (used by another project):
>   set(KCoreAddons_LIBRARY_TARGETS KF5::KCoreAddons)

... because I think this is subpar.

> Works right now, no new features to learn, no new code to add to cmake,
> standard names, and now with added guarantees.

What added guarantees? You mean the variables in cmake are handled differently 
now? Or just because of the usual extra-layer of indirection?

> I mean, setting and using variables is more or less the most basic thing you
> do all the time in cmake. I am not aware of any complaints about variables
> in cmake (except the complaints about the ugliness of the cmake language in
> itself). If you don't like how cmake handles variables, maybe use something
> else.

And that's exactly the point, in the case of dependencies management at build 
time I don't like how cmake handles variables at all[*] (and I don't think I'm 
alone in that, most of the people touching our cmake files have problems with 
it at some point... except you because you breath and live cmake for good 
reasons). That's why another more secure tool is more than welcome for that 
case, this way we can use something else than variables when we want to.

Regards.

[*] If it had a strict mode like perl for instance, I'd have a different 
position on that matter I think. But I don't think it has anything like that.
-- 
Kévin Ottens, http://ervin.ipsquad.net

Sponsored by BlueSystems and KDAB to work on KDE Frameworks
-------------- 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-frameworks-devel/attachments/20130821/75cf0ea4/attachment-0001.sig>