D29299: Make KI18N_INSTALL() not rely on only LOCALE_INSTALL_DIR

Pino Toscano noreply at phabricator.kde.org
Thu Apr 30 19:28:47 BST 2020


pino added a comment.


  In D29299#660614 <https://phabricator.kde.org/D29299#660614>, @kossebau wrote:
  
  > In D29299#660519 <https://phabricator.kde.org/D29299#660519>, @pino wrote:
  >
  > > In D29299#660505 <https://phabricator.kde.org/D29299#660505>, @kossebau wrote:
  > >
  > > > Because people do strange things, and I prefer to rather not break their card house unless necessary.
  > >
  > >
  > > Again, in which cases? The only way it might change the path is: use ki18n AND build with cmake AND use the ki18n_install macro AND define a KDE_INSTALL_LOCALEDIR variable yourself. Too many factors to make it even something to even bother thinking about TBH.
  >
  >
  > Mileages difer :)
  >
  > One does not need to define KDE_INSTALL_LOCALEDIR oneself. One only needs to use find_package(KF5Plasma) or find_package(KF5Package), because some subrepo also does a plasma applet for Plasma integration or have someone cluelessly copied cmake code together because ENOTIMEFORBUILDSYSTEM and copying from the best=KDE and now-it-builds-so-do-not-touch-again.
  
  
  In this case it will be generated automatically, and it will be the same as LOCALE_INSTALL_DIR.
  
  > I have seen quite some cmake code, otherwise I would not be so passive here in the change (and yes, there is a world outside kde repos) :)  And when you recommneded ki18n outside of kde spheres over the sad Qt i18n stuff, you do not want to see things falling apart, You yourself might not bother, but I do, because I have been hit myself too often in my life by people carelessly changing default things in minor releases, because worksformecanotimaginesomethingstrangewhybother.
  
  Let me clarify: I **do** care about software outside kde.org, you are definitely not the only one that does that. What I wrote above about "not bothering" refers to //that// specific situation I listed, not to everything else.
  I'm also one of the people that says "beware of compatibility"... when it makes sense. In this case, I do not see anything to keep compatibility with, and the only situation is already a broken case on its own.
  
  Again: beside what I said earlier, do you see any **actual** potential other scenarios, nor situation where what I proposed would not be safe?
  
  > Why stop people caring for doing things more safely? :)
  
  I am not, please do not put thoughts in my mind that were not mine, thanks :)

REPOSITORY
  R249 KI18n

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

To: kossebau, ilic, heikobecker, #frameworks, aacid, ltoscano
Cc: 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/20200430/bfdf0211/attachment-0001.html>


More information about the Kde-frameworks-devel mailing list