KF5 Update Meeting Minutes 2013-w31

Stephen Kelly steveire at gmail.com
Wed Jul 31 11:37:52 BST 2013


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?


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

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

Thanks,

Steve.






More information about the kde-core-devel mailing list