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