vkrause added a comment.
In D13816#286689 <https://phabricator.kde.org/D13816#286689>, @apol wrote: > It does have some advantages, I personally thing though that we shouldn't be compromising code readability and convenience for size, but I don't know how much better it is shared vs static. Yep. I don't have numbers yet for KDE examples (as we can't build a working test-case at this point), from what I have seen at work I'd expect something in the 2x-3x range compared to a dynamic build, as well as some small startup speed gains (in the 100ms range). Maybe it's just me, but our APKs still feel a bit heavy to me (KDE Itinerary is now at 27M here, for what's essentially a list view), therefore I'm exploring this option a bit. > If we need to have a list of `<frameworkname>::init()` with all frameworks we depend on, it will be a bit odd and error prone, but it could be useful. Yep, I don't like this at all either. However, you will only need this in your application code, and only if you explicitly want to statically link it (ie. no impact for "normal" applications). And it wont be needed for all libs either, only those that rely on static construction somehow (qrc, qm catalog loaders, etc) and don't have a natural entry point or (internal) singleton already anyway (my best guess at this point, maybe 1/3). Not that this makes it less error prone though, on the contrary even. So for me this boils down to: do we want to enable users of (some of) our frameworks to do static builds and are we willing to accept the ugliness this brings with it? Or does anyone have an idea how to solve this more elegantly? :) REPOSITORY R1003 KItinerary: Travel Reservation handling library REVISION DETAIL https://phabricator.kde.org/D13816 To: vkrause, #frameworks Cc: apol, kde-pim, dvasin, rodsevich, winterz, vkrause, mlaurent, knauss, dvratil
