D7706: Use runtime install prefix instead of compile time install prefix.
David Faure
noreply at phabricator.kde.org
Tue Dec 19 23:06:19 UTC 2017
dfaure added a comment.
QStandardPaths::InstallLocation cannot ever exist, if you mean by that "the install location for KF5" or "the install location for a KF5-based application". How would that work? There could be (at least) 3 different install locations, at least on Unix: one for Qt, one for KF5, and one for the app. Qt only knows about the first one, currently.
But OK, this code here is Windows-specific, and there we control the install layout, so if Qt, KF5 and KF5-based apps will always be installed into the same prefix, then this patch is OK. Are we sure this will always be the case though?
The rest of your comment is about CMAKE_INSTALL_PREFIX usage everywhere. I am very opposed to adding a dependency on kcoreaddons everywhere, even a header-only dependency, it breaks the whole point of independently reusable frameworks for commercial application developers out there. However many frameworks already depend on kcoreaddons so we could use a kcoreaddons method there, and duplicate it in the other ones -- after all we're talking about a 5 liner with #ifdef / return / #else / return / #endif.
There is a completely different solution: adding to Qt a method that takes a function address and returns the full path to the binary (shared lib or executable) containing that function. Volker provided us with an implementation for this: https://github.com/KDAB/GammaRay/blob/master/common/selflocator.cpp
Then any framework could easily find where it is installed, by calling this with the address of one of its own functions.
This would be a much cleaner solution, because it wouldn't rely on Windows setups to install everything into the same dir as Qt, like this patch does.
INLINE COMMENTS
> habacker wrote in kinit_win.cpp:205
> not in KF5, see comments in this bug
Which bug? you mean this review request? I don't see a bug reference.
REPOSITORY
R303 KInit
REVISION DETAIL
https://phabricator.kde.org/D7706
To: habacker, dfaure, ltoscano, bcooksley
Cc: dfaure, #frameworks
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kde-frameworks-devel/attachments/20171219/367f1e2c/attachment.html>
More information about the Kde-frameworks-devel
mailing list