n Thu, Sep 24, 2015 at 9:30 AM, David Faure <fa...@kde.org> wrote: > On Wednesday 23 September 2015 14:24:33 Harald Sitter wrote: >> Heya >> >> is it intentional that KCrash is not running when an application is >> started via kdeinit? >> >> In particular since only very few libraries seem to link KCrash it >> never gets loaded for 99% of applications, thus not installing as a >> qcoreapp crash handler and thus not handling crashes. >> Notably exception being forking from kdeinit (i.e. krunner a desktop file). >> >> It took me quite a while to notice that apps started from a terminal >> never get a drkonqi on crash and track that to kcrash not having its >> Q_COREAPP_STARTUP_FUNCTION run, so I think at best this is very >> unintuitive from a development perspective :) > > The plan was for all GUI apps to link to KCrash, and I think this is still the > best fix here. Someone needs to go through CMakeLists.txt for apps and add > KF5::Crash. > > Do people porting to KF5 follow a guide for the cmakelists.txt part of it? > That guide should mention this too ;)
Uh, ah, but, CMake is too smart :P If you add a target_link_library that isn't actually used it won't be linked. So what every application would have to do is add the target *and* call some function of KCrash so it actually links. Latter of course then defeats the purpose of the Q_COREAPP_STARTUP_FUNCTION. Ideally we'd first need a way to force cmake to link KF5Crash even if the target that wants to link it doesn't use it. I did a web search into that area yesterday but failed to come up with something useful unfortunately. HS _______________________________________________ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel