On Wed, 25 Feb 2015, Friedrich W. H. Kossebau wrote:
Am Dienstag, 24. Februar 2015, 09:47:41 schrieb Boudewijn Rempt:
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.
Hm, I have not seen this done elsewhere yet, can we be sure that all compilers
we are targetting (which I assume would be defined what Qt5/KF5 targets for
now) support this? And given you also target the 2.9 branch, which might mean
another set of compilers again. CentOS4(?)'s compiler supports it?
(Pardon, just stresstesting things I note down)
http://en.wikipedia.org/wiki/Pragma_once#Portability -- it really should
be fine. And we've had dozens of errors with header guards over time, to
it would be good to use a more fail-safe method of making sure headers get
included only once.
I guess nobody else uses it because of lingering ideas that gcc doesn't
support it, but gcc on CentOS 6.4 is 4.something, so that's fine.
* 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)
I am not sure everyone of the maintainers is yet convinced that this is okay
WRT git blame. Has consensus been reached there meanwhile? Any parts of the
repo which should be left out (Kexi?)?
This is a whole list, and parts of it are really a good thing, like fixing
the includes. We don't want, absolutely not, QModule/QClass style includes
while porting. That's such a disaster. (And it was a bad idea to begin
with, just makework -- why should anyone need to remember which module a
Qt class comes from?) I did something similar with the previous Qt5 port,
as well as making sure that all our kde includes were consistent.
Other parts, well, it depends on what I end up porting. I need libs,
plugins and krita and parts of karbon. I won't touch any other
application.
For the rest of the scripts, I intend to use them on pigment and krita at
least.
Noted.
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
Any takers? Noted.
* 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.
Noted.
>> *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?
Should be, both master and 2.9 branch. Toplevel _build_ dir, sorry, was not
precise enough.
Ah, right!
> 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:
Okay :)
>> 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 :-)
Noted.
Cheers
Friedrich
_______________________________________________
Krita mailing list
kimages...@kde.org
https://mail.kde.org/mailman/listinfo/kimageshop
_______________________________________________
calligra-devel mailing list
calligra-devel@kde.org
https://mail.kde.org/mailman/listinfo/calligra-devel
