<table><tr><td style="">dfaure 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/D7706" rel="noreferrer">View Revision</a></tr></table><br /><div><div><p>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.</p>

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

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

<p>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: <a href="https://github.com/KDAB/GammaRay/blob/master/common/selflocator.cpp" class="remarkup-link" target="_blank" rel="noreferrer">https://github.com/KDAB/GammaRay/blob/master/common/selflocator.cpp</a><br />
Then any framework could easily find where it is installed, by calling this with the address of one of its own functions.<br />
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.</p></div></div><br /><div><strong>INLINE COMMENTS</strong><div><div style="margin: 6px 0 12px 0;"><div style="border: 1px solid #C7CCD9; border-radius: 3px;"><div style="padding: 0; background: #F7F7F7; border-color: #e3e4e8; border-style: solid; border-width: 0 0 1px 0; margin: 0;"><div style="color: #74777d; background: #eff2f4; padding: 6px 8px; overflow: hidden;"><a style="float: right; text-decoration: none;" href="https://phabricator.kde.org/D7706#inline-42505" rel="noreferrer">View Inline</a><span style="color: #4b4d51; font-weight: bold;">habacker</span> wrote in <span style="color: #4b4d51; font-weight: bold;">kinit_win.cpp:205</span></div>
<div style="margin: 8px 0; padding: 0 12px; color: #74777D;"><p style="padding: 0; margin: 8px;">not in KF5, see comments in this bug</p></div></div>
<div style="margin: 8px 0; padding: 0 12px;"><p style="padding: 0; margin: 8px;">Which bug? you mean this review request? I don't see a bug reference.</p></div></div></div></div></div><br /><div><strong>REPOSITORY</strong><div><div>R303 KInit</div></div></div><br /><div><strong>REVISION DETAIL</strong><div><a href="https://phabricator.kde.org/D7706" rel="noreferrer">https://phabricator.kde.org/D7706</a></div></div><br /><div><strong>To: </strong>habacker, dfaure, ltoscano, bcooksley<br /><strong>Cc: </strong>dfaure, Frameworks<br /></div>