Fwd: Reminder: use KF5::foo instead of ${foo_LIBRARIES} in CMakeLists

[Aurélien Gâteau]

On Wednesday 25 September 2013 12:04:11 Aurélien Gâteau wrote:
> On Wednesday 25 September 2013 11:22:57 Sebastian Kügler wrote:
> > CMake-gods, can you confirm the below? (It's inconsistent with my
> > understanding, and how we've done it in the past months, I'd like to have
> > a
> > specialist opinion before going around and changing every single
> > CMakeLists.txt in Plasma.)
> 
> My cmake-fu is far from god-level, but my experience is that for frameworks
> to build standalone, they must link to other frameworks using
> ${foo_LIBRARIES} rather than KF5::Foo.
> 
> I take it this is the reason kdelibs/CMakeLists.txt defines many
> ${foo_LIBRARIES} variables.

Replying to myself: this topic was discussed on IRC with Stephen Kelly, the 
result is the following:

# Short version

1. To use the "Foo" framework within another framework whose code is in 
kdelibs, use "Foo":

	target_link_libraries(bar Foo...)

2. To use the "Foo" framework outside of kdelibs, use "KF5::Foo":

	target_link_libraries(external_project KF5::Foo)

3. Standalone builds of tier2 and tier3 are not possible for now.

# Long version

When building all of kdelibs, a framework can refer to other frameworks by 
their target name since they are all part of the "kdelibs" cmake project. For 
example, KCompletion can link to KConfigCore like this:

	target_link_libraries(KCompletion LINK_PRIVATE KConfigCore)

When building KCompletion standalone, it is no longer part of the "kdelibs" 
cmake project and cannot find KConfigCore, one would thus need to change the 
target_link_libraries call to this:

	target_link_libraries(KCompletion LINK_PRIVATE KF5::KConfigCore)

But that would break the all-in-one build of kdelibs, since in this context 
KF5::KConfigCore is not defined.

The solution to this is ALIAS targets, as explained by Stephen here:
http://thread.gmane.org/gmane.comp.kde.devel.core/80233/focus=80247

With ALIAS targets, one would define an alias like this when building kdelibs:

	add_library(KF5::KCoreAddons ALIAS KCoreAddons)

This would make it possible for the kdelibs all-in-one build to find 
KCoreAddons.

Unfortunately, ALIAS is a new feature of the add_library command, which is 
only available in cmake git for now and will be in 2.8.12. Therefore we cannot 
use this solution right now. This means we can't have standalone builds of 
tier2 and tier3 frameworks. tier1 frameworks are OK since by definition they 
do not depend on other frameworks.

The alternative syntax: ${KConfigCore_LIBRARIES} would work in both cases, but 
it is more error prone: any typo in the variable name causes the variable to 
be expanded to an empty string, making it more difficult to debug, whereas 
using target names provide more explicit error messages.

Aurélien