D13816: Make KItinerary work as a static library

[Emmanuel Lepage Vallee]

lepagevalleeemmanuel added a comment.


  > Right, that works for plugins. There is even https://codereview.qt-project.org/#/c/195680/ since 5.11 allowing us to hook "plugin loading", for things covered by static construction in the dynamic case. The patch here is looking more at something like the bug report you mentioned below, ie. use of static construction in libraries rather than plugins.
  
  Sorry, my bad, it has been a while and I totally got confused about that part. Yes, indeed, only some frameworks like Kirigami and QQC2-ds are plugins. The others are just normal libs.
  
  > That bug report is more what I'm looking at here. I disagree with your assessment though that this is undefined behavior or broken in the current dynamic code. Static construction is actually a pattern used all over the place, among them are qrc, the qml compiler and the ECM qm catalog loader, as well as custom code as you found in KConfig, or as this patch tries to support in KItinerary. So I think we need a proper solution for this.
  
  Static construction is fine. The issue here is a lot more subtle. Let's take a similar case. Back when the distributions started to use the `--as-needed` LDFLAGS, there was a lot of this issue too. If a library is not used, then you can't "trust" that the static code will get executed because the linker has the "right" to drop whole .so. When using LTO, you get this issue on the compilation unit level. So a `.o` can be dropped entirely if nothing points to that CU, even if static init from that CU point to other CU. This is why static code needs to be handled with care on them. It isn't forbidden, it just can't be "trusted" to be executed. In the case of the kconfig bug, it clearly isn't executed with very bad consequences. It is not a gold linker bug, it's just how LTO dead code elimination works.
  
  > Most of those patches seem to be dealing with the Qt5::Test dependency or other dependency-related changes, ie. this should be pretty harmless to integrate?
  
  Yes and no. The majority is easy, but there is a very hard minority of changes that will be enormously controversial.
  
  The easy basic:
  
  - Allow to disable Qt::Test because LTO-ing test takes too much resources to be ran in every CI build
  - Stop using "SHARED" in add_library and always use the "BUILD_SHARED_LIBS ON" option
  - Fix all cmake "targets" to have the correct dependencies exported to avoid adding manual `-lkf5foo` due to misexported deps
  - For the framework that are Qt plugins, add the necessary MOC arguments
  
  The much harder parts:
  
  - There is some new classes of bugs like dead code elimination having side effects
  - Some things like Kio "hard" dependencies have to go or undergo large redesign because they often are used in a single line of code (file picker widget) and pull 10 frameworks that make no sense for static binaries.
  - Everything using client-daemon or multi-process model become very impractical on Android and other bundles
  - Everything that uses dlopen is potentially broken
  - All KDE deamons like kdeinit5/kded5/knotify need to be reconsidered because they make no sense in sandboxes and have bad side effects like increased binary size instead of a reduction due to each binary having its own Qt
  - Things like the icon theme and resource should to have some ways of getting bundled to have "portable" binaries
  - Some external customization like icon theme, color scheme and theme break
  
  Ideally / eventually / hopefully:
  
  - The kconfig kcfg compiler need either to be rewritten without Qt or exposed as web service because it is "incompatible"/"impractical" with cross-compilation
  - The breeze icon pack generator and translation compiler also need some work to be easier to integrate
  - We need a CI to validate the result and detect regression otherwise it will break again after 1 week
  
  For the last 2, I mix static builds with "container driven cross compilation" issues. It's not fully relevant to static libs, but rather the use case for them,
  
  So in the end, it's not simple and will make some people very unhappy. The patches I maintain is the strict minimum for ring-kde to link and work. It isn't a clean job and it isn't the complete picture. I felt like this isn't something I can just start submitting patches and eventually finish. It needs buy-in from a lot of people and I am not sure it can happen without face to face discussion at Akademy or something.

REPOSITORY
  R1003 KItinerary: Travel Reservation handling library

REVISION DETAIL
  https://phabricator.kde.org/D13816

To: vkrause, #frameworks
Cc: mart, lepagevalleeemmanuel, apol, kde-pim, dvasin, rodsevich, winterz, vkrause, mlaurent, knauss, dvratil
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kde-frameworks-devel/attachments/20180709/1e727bbe/attachment.html>