<table><tr><td style="">vkrause added a comment.
</td><a style="text-decoration: none; padding: 4px 8px; margin: 0 8px 8px; float: right; color: #464C5C; font-weight: bold; border-radius: 3px; background-color: #F7F7F9; background-image: linear-gradient(to bottom,#fff,#f1f0f1); display: inline-block; border: 1px solid rgba(71,87,120,.2);" href="https://phabricator.kde.org/D13816">View Revision</a></tr></table><br /><div><div><blockquote style="border-left: 3px solid #8C98B8;
          color: #6B748C;
          font-style: italic;
          margin: 4px 0 12px 0;
          padding: 8px 12px;
          background-color: #F8F9FC;">
<div style="font-style: normal;
          padding-bottom: 4px;">In <a href="https://phabricator.kde.org/D13816#286689" style="background-color: #e7e7e7;
          border-color: #e7e7e7;
          border-radius: 3px;
          padding: 0 4px;
          font-weight: bold;
          color: black;text-decoration: none;">D13816#286689</a>, <a href="https://phabricator.kde.org/p/apol/" style="
              border-color: #f1f7ff;
              color: #19558d;
              background-color: #f1f7ff;
                border: 1px solid transparent;
                border-radius: 3px;
                font-weight: bold;
                padding: 0 4px;">@apol</a> wrote:</div>
<div style="margin: 0;
          padding: 0;
          border: 0;
          color: rgb(107, 116, 140);"><p>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.</p></div>
</blockquote>

<p>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).<br />
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.</p>

<blockquote style="border-left: 3px solid #a7b5bf; color: #464c5c; font-style: italic; margin: 4px 0 12px 0; padding: 4px 12px; background-color: #f8f9fc;"><p>If we need to have a list of <tt style="background: #ebebeb; font-size: 13px;"><frameworkname>::init()</tt> with all frameworks we depend on, it will be a bit odd and error prone, but it could be useful.</p></blockquote>

<p>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.</p>

<p>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?</p>

<p>Or does anyone have an idea how to solve this more elegantly? :)</p></div></div><br /><div><strong>REPOSITORY</strong><div><div>R1003 KItinerary: Travel Reservation handling library</div></div></div><br /><div><strong>REVISION DETAIL</strong><div><a href="https://phabricator.kde.org/D13816">https://phabricator.kde.org/D13816</a></div></div><br /><div><strong>To: </strong>vkrause, Frameworks<br /><strong>Cc: </strong>apol, kde-pim, dvasin, rodsevich, winterz, vkrause, mlaurent, knauss, dvratil<br /></div>