D29299: Make KI18N_INSTALL() not rely on only LOCALE_INSTALL_DIR

[David Faure]

dfaure added a comment.


  In D29299#676447 <https://phabricator.kde.org/D29299#676447>, @pino wrote:
  
  > In D29299#676446 <https://phabricator.kde.org/D29299#676446>, @dfaure wrote:
  >
  > > In D29299#676445 <https://phabricator.kde.org/D29299#676445>, @pino wrote:
  > >
  > > >
  > >
  > >
  > > 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.
  
  
  OK sorry for stating the obvious then.
  When you wrote "ki18n_install() is basically used by KF sources that use ECM already" it seemed to me that this was looking at KDE community code only; it's hard to make such a broad statement if including also external code. If you agree that being able to use ki18n without ECM is better, then indeed we all agree.
  
  > Sure. But it is not what I referred to when I spoke about "broken code".
  
  I have to apologize again, then, because I don't understand what is the "broken code" we're talking about then.
  
  > 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?
  
  We do agree on this. I don't think I was painting you that way at all. I'm merely trying to understand both sides of the argument and find a solution that works for everyone.
  
  >> 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)
  
  Would this be what is done in D29303 <https://phabricator.kde.org/D29303>? (I just learned about this third option...)

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/6fae2ce9/attachment.htm>