KF5 Update Meeting Minutes 2013-w31

[Alexander Neundorf]

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.
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.
Doesn't feel like much fun to spend my spare time this way.

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

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)

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

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.

Alex