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@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. I'd like to have a mean for people to learn and fix it themselves as they go instead of relying only on you and Alex as you're both randomly available (which is fine in itself, but means we need the doc mentioned above). Please teach us to fish... Regards. -- Kévin Ottens, http://ervin.ipsquad.net KDAB - proud supporter of KDE, http://www.kdab.com
signature.asc
Description: This is a digitally signed message part.