KF5 Update Meeting 2013-w20

[Kevin Ottens]

On Wednesday 15 May 2013 21:07:43 Alexander Neundorf wrote:
> On Wednesday 15 May 2013, Kevin Ottens wrote:
> > Hello all,
> > 
> > So yesterday 4pm (Paris timezone :p) as planned we had the first update
> 
> is it planned to have those meetings sometimes also later in the day ?
> At 4pm I'm at work, and so can't attend.

I'd have some other personal commitments later in the day... maybe that could 
happen one hour later though. Would that work for you?

> > Action items:
> >  * [ervin] Send meeting reminders on mondays
> >  * [dfaure] Import QCommandLineArgs in qt5kdestaging
> >  * [dfaure + ervin] Discuss the upcoming KIO split
> >  * [steveire] Look into the SOVERSION issue, and cleanup the CMake files
> 
> I had a look at KConfigWidgets. It has
> 
> ecm_setup_version(5 0 0 VARIABLE_PREFIX ITEMVIEWS
>                   VERSION_HEADER kconfigwidgets_version.h
>                   PACKAGE_VERSION_FILE KConfigWidgetsConfigVersion.cmake)
> 
> 
> i.e. the macro will setup the variables
> ITEMVIEWS_VERSION_(MAJOR|MINOR|PATCH)
> (as documented in ECMSetupVersion.cmake) which is most probably not wanted,
> and then uses

Woops, ok, my bad then. Glad you looked I got through that line several times 
without seeing the problem. :-)
Fixing it right away.
 
> For the cleanup, my plan would be to get rid of
> * ECMVersion.cmake
> * ECMQtFramework.cmake
> * ECMQtFrameworkConfig.cmake.in
> * ECMWriteVersionHeader.cmake

Sounds good we don't particularly use them.
 
> I'm also not too excited about ECMMarkAsTest.cmake and
> ECMMarkNonGuiExecutable.cmake, since both basically only wrap a call to
> set_target_properties().
> In all the CMakeLists.txt in the test directories there is very similar code
> for generating the test executables, refactoring that into a generically
> useful macro would be nice.

Agreed. I think it'd be much better than the current ECMMark* macros which 
don't buy us much.

> Beside that, I would like if we could do a release of extra-cmake-modules as
> soon as possible, so other projects, KDE and non-KDE can start to make use
> of it and people can start to contribute.

I guess that once we're happy with the cleanup pass that's something which 
could be done.

> >  * [steveire] Write a "CMake for frameworks" guideline in the wiki
> >  * [ervin] Talk to Ben about having our own qt5.git with a kf5 branch
> >  * [notmart] Look at cleaning up the CMake files in plasma-framework (if
> > time permits)
> 
> Last time I looked it didn't look too bad.
> As long as kdelibs is only partly split some somewhat ugly things have to
> stay around I think.
> Do you have anything special in mind ?

Well, it's mostly about the find_package calls I think. The list is quite 
extensive and I think it tries to find much more than it needs, the most 
likely culprit being the use of KDELibs4 which itself forces you to pull 
everything (see the growing list of find_package(KF5 ...)? it's forced by 
KDELibs4 apparently).

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-core-devel/attachments/20130516/8c26a9c5/attachment.sig>
-------------- next part --------------
_______________________________________________
Kde-frameworks-devel mailing list
Kde-frameworks-devel at kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel