D29299: Make KI18N_INSTALL() not rely on only LOCALE_INSTALL_DIR

[Pino Toscano]

pino added a comment.


  In D29299#676446 <https://phabricator.kde.org/D29299#676446>, @dfaure wrote:
  
  > 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.
  
  
  Sigh. I know this, I never, ever, ever, and let me say it again, **never**, forgot about this.
  
  > 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?
  
  Sure. But it is not what I referred to when I spoke about "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.
  
  Yes, sorry, you are not Friedrich. OTOH, it would be nice to not be painted as "the one that wants to break things without second thoughts". Can we please agree on this? Because if not, there is no more point for me to keep contribute to a discussion.
  
  Again, I already proposed a technical solution. Let me quote it again:
  
  In D29299#660465 <https://phabricator.kde.org/D29299#660465>, @pino wrote:
  
  > > The patch should not require existing users to adapt
  >
  > Yes, that's also what I wrote earlier.
  >
  > Also, your patch basically includes D29136 <https://phabricator.kde.org/D29136> in the case of no DESTINATION parameter specified, hence my suggestion is:
  >
  > - edit D29136 <https://phabricator.kde.org/D29136> to do the fallback using the same logic introduced here: this way marble is already fixed with no other changes, and ki18n_install will work also with KDE_INSTALL_DIRS_NO_DEPRECATED (e.g. for release-service packages)
  > - have this to add the DESTINATION parameter, so packages can opt-in to use it if they can/want

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/dfa17d4c/attachment-0001.htm>