RFC: plan for starting the Qt5/KF5 port

Boudewijn Rempt boud at valdyas.org
Tue Feb 24 08:47:41 UTC 2015


Sorry, I have to interline in Jaroslaw's answer -- apparently I lost my 
copies of the original mail, or they never arrived :-(

As a sidenote, I also want to take the opportunity to do a clean-up step, 
but I'm not sure what the right moment or place is. It might even 
something to do in the 2.9 branch after tagging...

* replace all header guards with '#pragma once' -- because errors with 
header guards are actually quite frequent, and all compilers support this 
pragma now.

* rename all krita files to the calligra standard. (cc -> cpp, underscore 
-> CamelCaps)

* from kde-dev-scripts, run:
** astyle-kdelibs (prevents the astyle problems with foreach and so on)
** clean-forward-declaration.sh (remove unused forward declarations)

* from plasma-framework, run:
** port-qslots.sh (to port to Q_SLOTS and Q_SIGNALS)
** port-includes.sh (to get rid of the module prefixes in includes)
** port-cmake-style.sh (to get a bit more consistency)

For the rest of the scripts, I intend to use them on pigment and krita at 
least.

There are also some things that might need more thinking beforehand:

* plugin loading. This changed a lot in KF5. We already didn't use the 
sycoca anymore for loading plugins, and we probably can, for now, still 
use the .desktop file system to find plugins. However, we should check the 
old Qt5 porting branch and see if we can re-use its plugin loader. That 
uses the new Qt5 plugin+json combination already. Check KoJsonTrader.cpp

* That branch also contains some patches for Qt regressions (like 
bcd822eac52e09b6bf7a4c9fe293c9b3234a6486 or 
a5361d299b3991f9414466ad9d0c83537e6f2778), so it might be useful to refer 
to it while porting the libs, Words, Sheets and Stage.


On Tue, 24 Feb 2015, Jaroslaw Staniek wrote:

> On 24 February 2015 at 03:55, Friedrich W. H. Kossebau <kossebau at kde.org> wrote:
>> Hi,
>>
>> rough plan was to start porting after the 2.9 release. Whose dates are:
>>
>> Tagging February 24nd (moved from 22nd)
>> Release February 26th
>>
>> To get some patches in that do not fit for the 2.9 branch and otherwise would
>> bitrot due to the Qt5/KF5 port, there will be a merge window for master.
>> Everyone having some WIP stuff that is good enough for merging, brush it up
>> now and get it in!
>>
>> "Merge window for master" until: Wed March 4th (proposed)

Right.

>> "Porting start": same day of merge window close
>>
>> Porting branch named "frameworks" usually, some stuff expects it even.
>>
>> Initial porting steps (done by 1 person):
>> -----------------------------------------
>> 1. Merge "calligra/2.9" another time into "master"
>> 2. Branch off "frameworks" from "master"
>> 3. Apply https://git.reviewboard.kde.org/r/121541/
>> 4. Remove these subdirs:
>>    3rdparty/kdchart/
>>    3rdparty/kdchartpatches/
>>    3rdparty/kdgantt/
>>    3rdparty/kdganttpatches/
>>    libs/koproperty/
>>    libs/koreport/
>>    (anything else moved outside?)
>
> At least:
> plugins/reporting/
> libs/db/
> some of cmake/modules/* (discussed yesterday with me)
>
>> 5. Port just the buildsystem to Qt5/KF5/ECM as much as needed to get "cmake"
>> configure pass and "make" && "make install" also pass with success, without
>> porting any code (should be all disabled still by step 3).
>> 6. Create commit and push "frameworks" branch to central Calligra repo
>> 7. Request a build on KDE CI for the "frameworks" branch
>> 8. Take disabled product from end of product dep tree* and make it build:
>>    1. remove "UNPORTED" tag
>>    2. port it as much as needed to make it build
>>    3. commit to "frameworks" branch
>> 9. if LIB_CALLIGRA has been added to the build, tell everyone to join
>>    goto 8. until there is no more "UNPORTED" tag
>>
>> *The dep tree of products can be either seen from content of
>> CalligraProducts.cmake or in a picture by using the generated
>> "product_deps.dot" in the toplevel dir:
>> dot -Tsvg product_deps.dot > product_deps.svg
>> or
>> dot -Tpng product_deps.dot > product_deps.png

That isn't in there already, right?

>>
>> Porting Rules (proposed):
>> -------------------------
>> * do not port away from kdelibs4support initally, but see to get it added to
>> the build as quickly as possible (only then go perhaps further)
>> * ensure CI always manages to build (to ease life of co-porters)
>> * love to the tests
>> * anything that needs temporarily to be disabled by commenting out should get
>>   a tag "QT5TODO" (anything better?), so it will not be forgotton before 3.0
>>
>
> A candy to users of Qt Creator: http://i.imgur.com/4Rz0W0T.png

Meh, mine doesn't have that!

> Any set of tags can be configured. Feel free to append invent tags
> like KRITA3 or KRITAQT5.
> So you can filter the tags easier in your area of interest, make the code
> navigation easier.
> I am sure vim/emacs users have their habits and the tags can work for
> them as well.
>
>> Reasoning:
>> ----------
>> Calligra has over 4 M lines (claims openhub.net, not counted myself), so
>> expecting one person to do all the initial porting would be quite some burden
>> to that. Also is noone expert in all code.

Sloccount counts 1,771,776:

524137  krita           cpp=521558,ansic=2172,javascript=295,perl=68,sh=44
330485  3rdparty        cpp=231009,python=37741,sh=22458,java=17017,ansic=16730,
                         objc=5124,asm=236,lisp=89,batch=78,ruby=3
219626  libs            cpp=217692,yacc=805,ansic=765,lex=313,sh=51
184231  filters         cpp=180916,perl=1864,java=1197,ansic=161,sh=93
112978  plan            cpp=108546,ansic=2378,python=2022,sh=32
108477  kexi            cpp=101074,ansic=6490,sh=806,java=107
100256  sheets          cpp=97520,python=2507,ruby=168,sh=61
97944   plugins         cpp=94654,yacc=1817,lex=1107,sh=161,perl=126,python=79
28004   stage           cpp=27858,perl=142,sh=4
19517   words           cpp=17253,python=1670,ruby=566,perl=19,sh=9
16682   karbon          cpp=16671,sh=11
8579    gemini          cpp=8084,javascript=495
5636    devtools        cpp=3227,python=1912,sh=281,perl=216
5504    braindump       cpp=5497,sh=7
3183    qtquick         cpp=3183
2343    active          cpp=2340,sh=3
1566    flow            cpp=1502,sh=64
872     extras          cpp=842,sh=30
859     windows         batch=751,python=73,vbscript=35
357     doc             perl=357
199     winquirks       ansic=199
177     interfaces      cpp=177
106     top_dir         sh=55,ansic=51
58      cmake           ansic=58

:-)


>> The proposed UNPORTED tag system (see step 3. above) and the initial porting
>> product-by-product as much as needed to get it build at least should help to
>> parallelize the work quickly, so everyone can give special love to the code
>> they care for.
>> Sadly krita is not "product"ed, so there it will be more a matter of control
>> by commenting in CMakeLists.txt. Surely also doable :)
>>
>> To not have people step on each other toes and do conflicting work, I will add
>> a wiki page where people can "take" a product before they start working on
>> making it build (and where I possibly should also dump this plan).
>> Any proposal for the location and name of the wiki page below
>> community.kde.org/Calligra ?
>
> Wiki tables unless heavily splited to sections are barely interactive.
> Unfortunately (because Kexi should be used for that in the cloud) I
> have to propose a Google docs spreadsheet for real time editing of
> what's done, what's a TODO.

I agree.

>
>> On #kde-devel the recommendation was to not blindly run any porting scripts
>> that are available, but rather decide case-by-case if to run the script or
>> just do manual porting. Another reason why splitting the porting work into
>> different people makes more sense.
>
> A rule I propose: always mention in a commit message the what script
> was used and have one commit per run (exception: trivial changes).
>
>> I expect different parts of Calligra to go different miles for 3.0. Some might
>> port away from kdelibs4support as there is not a lot to do, some might be
>> happily using it for 3.0. Both should be very fine.
>> Important are as few regressions as possible and something that is usable :)
>>
>> Comments, please.

After 3.0, for 3.1, I want to split up our repository. It's just getting 
too unwieldy to manage. That's as far as my thinking has gone :-)


>
> Looks good but I am before my coffee...
>
>> PS: Tomas, you had done some initial buildsystem porting experients, right?
>> Would you be willing to be the person to do the initial porting steps?
>
> PS: in what time zone are you at the moment? :)
>
> -- 
> regards, Jaroslaw Staniek
>
> KDE:
> : A world-wide network of software engineers, artists, writers, translators
> : and facilitators committed to Free Software development - http://kde.org
> Calligra Suite:
> : A graphic art and office suite - http://calligra.org
> Kexi:
> : A visual database apps builder - http://calligra.org/kexi
> Qt Certified Specialist:
> : http://www.linkedin.com/in/jstaniek
> _______________________________________________
> Krita mailing list
> kimageshop at kde.org
> https://mail.kde.org/mailman/listinfo/kimageshop


More information about the kimageshop mailing list