< Calligra | Schedules Revision as of 00:42, 23 March 2015 (view source)Yue2 (talk | contribs) (→Stuff that can be removed)← Older edit Revision as of 09:40, 23 March 2015 (view source) Frinring (talk | contribs) m (→General)Newer edit → Line 12: Line 12: == General == == General == −* Porting branch named "frameworks" usually, some stuff expects it even.+* Porting branch: "frameworks" * Min Qt5 version: 5.2 (matches current KF5 min required version) * Min Qt5 version: 5.2 (matches current KF5 min required version) * Min KF5 version: 5.? * Min KF5 version: 5.? Revision as of 09:40, 23 March 2015 Contents 1 Dates 2 Patches to merge 3 General 4 Porting Rules 5 Porting Helpers 6 Porting Notes 7 Porting Targets 8 Stuff that can be removed 9 Stuff to be done before the port 9.1 Reformatting 9.1.1 Under discussion still 9.1.2 Not to be done 9.2 Prepare architecture/technology changes 10 Stuff not to be done for 3.0 11 Initial porting steps 12 Links Dates "End of Merge window for master"^ until: Wed March 4th (proposed) "Porting start": same day of merge window close ^ 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! Patches to merge Paste links to patches you want in master, so the window won't be closed too early. Remove them after submitting! General Porting branch: "frameworks" Min Qt5 version: 5.2 (matches current KF5 min required version) Min KF5 version: 5.? Min CMake version: ? (proposal: min required version of used KF5) Min ECM version: 1.? (proposal: min required version of used KF5) Porting Rules 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 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 To not have people step on each other toes and do conflicting work there will be a board on todo.kde.org where people can take a product before they start working on making it build. (TODO for Friedrich) Porting Helpers Calligra BuildPorting Work Organisation (Pick your task here) Frameworks 5 porting notes Qt5 Porting Guide Frameworks 5 apidox Frameworks 5 build instructions Building Calligra is still the same, just with new deps kde-dev-scripts.git on git.kde.org has useful porting scripts KDE5PORTING.html ECM API dox ECM SourceIncompatChanges http://www.proli.net/2014/06/21/porting-your-project-to-qt5kf5/ http://vizzzion.org/blog/2013/08/kde-frameworks-5-plugin-factory-guts To see changes done in the previous Qt5 port: git diff 9fb2dfcfe0ee0aeb032a149d65aae650172d4c9c origin/calligra-qt5-rempt -- some/subdir/or/files Porting Notes recommendation from #kde-devel: 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 some of the porting scripts conflict with using kdelibs4support ("e.g. if #include <KGlobal> has been removed, we might have to restore it") Porting Targets Different parts of Calligra will 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 :) Stuff that can be removed 3rdparty/kdchart/ 3rdparty/kdchartpatches/ 3rdparty/kdgantt/ 3rdparty/kdganttpatches/ libs/db/ libs/koproperty/ libs/koreport/ plugins/reporting/ plugins/formulashape/ flow/ kdchart & kdgantt are to be replaced by kdiagram (kchart,kgantt, ask frinring). db, koproperty & koreport are to be replaced by predicate, kproperty & kreport (ask jstaniek). Removing these libs/plugins will also render some Find*,cmake macros unneeded, but best check the buildsystem before just removing them. rewrite formulashape based on libmathview rewrite flow features in karbon Stuff to be done before the port Reformatting Any reformatting should be ideally done also in 2.9, to easy porting any further bug fixes. rename all krita files to the calligra standard. (cc -> cpp, underscore -> CamelCaps) from kde-dev-scripts, run: 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) rest of the scripts at least for pigment and krita (boud) Under discussion still from kde-dev-scripts, run: astyle-kdelibs (prevents the astyle problems with foreach and so on) Notes about how to apply it: https://docs.google.com/document/d/1jhq6oXuXKvTilJhcoS6FVKO7yYRu2yCgBS9ojhc2QRU/edit Pro: clean code Contra: "Applying full astyle is IMHO not OK, and even against efforts of everyone who keeps eye on proper coding style while doing code reviews." (jstaniek) "Secondly, breaking git blame is unacceptable. Unlike file renames, there's no equivalent of --follow or ignoring whitespace while patching, it's a massive irreversible break in history." (jstaniek)People who try this would have to work with scripts like these git-blame-prior-commits Not to be done replace all header guards with '#pragma once' "because errors with header guards are actually quite frequent, and all compilers support this pragma now." (boud) Reason against: not part of official spec, QtCreator fails on that, not very spread Prepare architecture/technology changes 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. Any takers? Stuff not to be done for 3.0 Splitting up the repository some more Initial porting steps done by 1 person Merge "calligra/2.9" another time into "master" Branch off "frameworks" from "master" Apply https://git.reviewboard.kde.org/r/121541/ Remove subdirs of stuff moved outside already 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). Create commit and push "frameworks" branch to central Calligra repo Request a build on KDE CI for the "frameworks" branch Take disabled product from end of product dep tree^ and make it build: make yours on https://todo.kde.org/?controller=board&action=show&project_id=73 remove "UNPORTED" tag port it as much as needed to make it build commit to "frameworks" branch if LIB_CALLIGRA has been added to the build, tell everyone to joingoto 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 build dir: dot -Tsvg product_deps.dot > product_deps.svg or dot -Tpng product_deps.dot > product_deps.png Links Porting Kexi to Qt 5 / KF 5 Retrieved from "https://community.kde.org/index.php?title=Calligra/Schedules/3.0/Porting_Plan&oldid=41947" Content is available under Creative Commons License SA 4.0 unless otherwise noted.