KF5 Update Meeting Minutes 2013-w31

[Alexander Neundorf]

On Wednesday 21 August 2013, Kevin Ottens wrote:
> 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.

Not much in KDE frameworks has been my decision at all.

> > 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?

The guarantees that
- the variable contains only targets
- that all targets contained in them exist
- that all targets have the necessary include dir property set
...and of course the standard naming all of you ignore.

> > 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.

Sorry, but I don't take this argument serious.
I mean, right now where we are looking for why using variables are bad, and 
indeed you can come up with reasons why variables are bad. That doesn't count. 
This works for anything, in every possible case.
It would have more weight for me if somebody who worked actively on the 
buildsystem in the last years, like Yury, or Sune, or Apaku, or Eike, would 
have said that.

I don't say cmake is perfect. Variables in cmake do have issues. The interplay 
between normal and cache variables is ... tricky. In if() tests for lists of 
values it is not really obvious what to expect as result. The handling of 
variables vs. strings in if( STREQUAL ) expressions is ...not good. Variables 
in macros could be problematic, for that case cmake has functions now.
I am aware of issues cmake has, and I don't deny them.

But in the last 7 years, I am not aware of any email on a KDE or cmake list, 
where a user complained seriously that cmake variables in general are hard or 
complicated to use (don't point me to emails from Brandon v.E.).

Alex