pino added a comment.
In D29299#676448 <https://phabricator.kde.org/D29299#676448>, @dfaure wrote: > 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 FWIW, I also checked https://sources.debian.org/ (which is the collection of sources in the Debian releases). I'm not aware of other services like this. In D29299#676448 <https://phabricator.kde.org/D29299#676448>, @dfaure wrote: > If you agree that being able to use ki18n without ECM is better, then indeed we all agree. If that wouldn't had been the case, it would have said to prefer D29136 <https://phabricator.kde.org/D29136>. >> 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. "broken code" is when a cmake script (mis)uses undocumented/internal bits/variables not documented as such. Or for example when you redefine macros, internal variables, or stuff like that. >>> 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...) Kinda, with the difference that it still prefers the deprecated variables. This is why I prefer D29136 <https://phabricator.kde.org/D29136>. 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
