<table><tr><td style="">kossebau 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/D29136">View Revision</a></tr></table><br /><div><div><p>I understand the desire for pragmatic solution, but I am too old now and have seen too many places where being pragmatic at one point resulted in tightly coupled systems which later prevented progress. <br />
When it comes to build dependencies, forcing users of a product to use the same build tools as used for the product is not well received by me in principle, as it lowers flexibility and choice as user.</p>

<p>So let me see for now how we can get ahead here without needing to extent KI18nConfig with find_dependecy(ECM).</p>

<p>Where would you see "that the macro already used KDEInstallDirs before"? When it comes to "LOCALE_INSTALL_DIR", that is set to a default is not set when calling the macro. Ideally would be documented though. (my first approach would be to also allow a soft dependency here on KDEInstallDirs, checking whether KDE_INSTALL_LOCALEDIR is defined and picking its value), similar with CMAKE_INSTALL_LOCALEDIR to support GnuInstallDirs automatically).</p></div></div><br /><div><strong>REPOSITORY</strong><div><div>R249 KI18n</div></div></div><br /><div><strong>REVISION DETAIL</strong><div><a href="https://phabricator.kde.org/D29136">https://phabricator.kde.org/D29136</a></div></div><br /><div><strong>To: </strong>heikobecker<br /><strong>Cc: </strong>kossebau, kde-frameworks-devel, LeGast00n, cblack, michaelh, ngraham, bruns<br /></div>