KF5 Update Meeting Minutes 2013-w31

[Kevin Ottens]

On Tuesday 30 July 2013 23:18:35 Alexander Neundorf wrote:
> On Tuesday 30 July 2013, Kevin Ottens wrote:
> >  * ben2367 is still looking in unifying our cmake files regarding
> >  variables vs direct use of targets;
> 
> Current conclusion (not yet merged into cmake, but will hopefully make it
> for 2.8.12): use ${PackageName_LIBRARY_TARGETS}.

Note that even though I didn't voice in the relevant thread yet I think it's a 
good fit *for now* so that we can build both kdelibs as a whole or as separate 
frameworks.

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.

Of course I think we should provide the variables to the outside for those who 
want it, but target should probably be encouraged. Anyway that's a "for later" 
discussion, for the time being we're kind of forced to use variables so that 
people who make the non-monolithic builds aren't blocked.

> Once the support for this is in cmake, cmake will guarantee that the
> contents of this variable all refer to existing targets, and that each of
> these targets has the INTERFACE_INCLUDE_DIRECTORIES property set, so that
> for the reader of a CMakeLists.txt a call like
> target_link_libraries(foo ${KCoreAddons_LIBRARY_TARGETS} )
> will guarantee that this thing contains targets, and that these targets come
> attached with the include dirs, so that no include_directories() call is
> necessary for KCoreAddons, in this example.
> No framework sets this variable yet.
> So from my side I don't see a need to hurry with this.
> 
> I'll have time again to work in this in roughly 3 weeks.

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

> >  * he's also working on the forwarding headers generation;
> >  * and last but not least he's making progress on a script to plot the
> > frameworks dependencies;
> 
> Dependencies to external packages or between the libraries within kdelibs ?

Within kdelibs.

> I guess you did have a look at cmake --graphviz=<filename> <buildir> ?
> If you use cmake git master, the options for modifying the output should now
> even be documented.

Yes, AFAIK that's what he's been using to build his script upon.

> > Action items still open:
> >  * [sandsmark] Finish the work on KPtyProcess
> >  * [steveire] Write a "CMake for frameworks" guideline in the wiki
> 
> I was about to start with that.

Again, please make that a team effort, I think I asked Steve to keep you in 
the loop when he picks that up... if it turns out that you pick it first I'd 
like the same thing from you: please work on it with Steve.

> I think it may make sense to have 3 separate sections:
> * using KDE frameworks libraries for 3rd party developers (i.e. Qt project
> which want to make use of one or another library)
> * using KDE frameworks for KDE software ("full blown" KDE applications)
> * 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.

Also I'm not sure I would make a difference between third party developers and 
KDE developers for the use of KF5. On the cmake front it should really be the 
same except for maybe some minor policy details (otherwise we're doing 
something wrong IMO).

Regards.
-- 
Kévin Ottens, http://ervin.ipsquad.net

Sponsored by BlueSystems and KDAB to work on KDE Frameworks
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.kde.org/pipermail/kde-frameworks-devel/attachments/20130731/e08b899f/attachment.sig>