D29299: Make KI18N_INSTALL() not rely on only LOCALE_INSTALL_DIR

[David Faure]

dfaure added a comment.


  In D29299#676445 <https://phabricator.kde.org/D29299#676445>, @pino wrote:
  
  > I asked for actual **valid** use cases when using the new variables first would break, and I still got none. There is a limit to how much you can keep broken code working... assuming such broken code exists. I don't think there is any of this such situation, as `ki18n_install()` is basically used by KF sources that use ECM already, with marble being the only exception (and even that, marble won't break).
  
  
  As you know, there are KF5-based applications outside the realm of what we can see in LXR.
  One of the primary goals of KF5 is to be useable by other applications not written by the KDE community (I actually know quite a few).
  As such, it's not hard to imagine a cmake-based application that uses Qt and GNUInstallDirs [with qmake going away this will happen more and more], and one day it wants to use one of the frameworks. At that point, it shouldn't be forced to switch to ECMInstallDirs. Therefore I definitely see value in keeping the two things separate, as long as we keep making things easy for what is the most common case for us: using both.
  
  This is why I'm requesting that the integration with ECM is called integration and not "backwards compat fallback".
  
  You say you don't want to support broken code. I agree. Would you agree that the situation I'm describing here is NOT broken code?
  
  > Oh, and just to make it clear: none of my comments implies that I don't care about ECM, nor about any users of it, nor that I "like" to purposefully break cmake scripts.
  
  I didn't say any of this, and you're replying to me here, not to Friedrich. I'm trying to bring this whole thing to a solution, so let's move aside all such accusations and concentrate on what might be helpful to resolve the technical issue.

REPOSITORY
  R249 KI18n

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

To: kossebau, ilic, heikobecker, #frameworks, aacid, ltoscano
Cc: dfaure, pino, kde-frameworks-devel, LeGast00n, cblack, michaelh, ngraham, bruns
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kde-frameworks-devel/attachments/20200912/61a14d8c/attachment.htm>