Review Request 126230: Make python, gettext and Qt5::QML optional for ki18n

[Chusslove Illich]

> On Дец. 4, 2015, 10:35 пре п., Chusslove Illich wrote:
> > The KI18N_INSTALL macro is also used by KI18n itself, to install its own translations. And so do other higher-tier frameworks. So I'm not sure when this no-Gettext/no-Python build is supposed to be useful. When one wants to omit translations?
> 
> Boudewijn Rempt wrote:
>     I _never_ install translations. Where would I install them from? Running "make install" in ki18n doesn't install translations, as far as I can see? I thought translations get installed by the distribution, or I package them manually for Windows and OSX. 
>     
>     So, when I build Krita on OSX or Windows, I first need to build the dependencies, and ki18n is one of them, but because it mixes up translation management with providing the translation framework an application uses. So why should I build Python and Gettext and QtQML for parts of this framework that never get executed?
> 
> Chusslove Illich wrote:
>     For me "make" does build translations using msgfmt, and builds some other translation-related files using a Python script, and "make install" installs those built files.
>     
>     Something is definitely going wrong if QtQML is seen as dependency. What is needed is QtScript, and that is a real dependency, used at runtime by translations. It can be disabled, but that will cause degradation in quality of some translations.
> 
> Chusslove Illich wrote:
>     Hm, where do you fetch the frameworks to build from? If from the Git repositories, there are no translations there. But the release tarballs do contain translations.
>     
>     Only Applications are released with separate translation packages. (Which I think is not a good thing, but hell...)
> 
> Boudewijn Rempt wrote:
>     Always from git.

If you are fetching and installing translations manually by taking only PO files, that will leave any scripted translations not working. Nothing will crash, but lower quality fallbacks will be used. If you want to support also scripted translations, you should fetch and install any modules from script/ subdirectories of translations in the repository.

Regarding this patch, I don't see it as appropriate, since it would basically allow for broken treatment of translations when building release tarballs. Better just add it to be applied in your build setup. I know, not nice when something changes and the patch needs to be updated, but it's the less bad alternative.


- Chusslove


-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/126230/#review89109
-----------------------------------------------------------


On Дец. 4, 2015, 1:17 пре п., Boudewijn Rempt wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/126230/
> -----------------------------------------------------------
> 
> (Updated Дец. 4, 2015, 1:17 пре п.)
> 
> 
> Review request for Build System, KDE Frameworks, Aleix Pol Gonzalez, Chusslove Illich, and Luigi Toscano.
> 
> 
> Repository: ki18n
> 
> 
> Description
> -------
> 
> When building ki18n as a dependency framework for shipping with an application, the tools to actually create and manage translations are superfluous. These tools have some big dependencies that are a pain to have around, especially gettext on Windows. This patch makes the requirement for Python and Gettext optional.
> 
> This patch checks the BUILD_TESTING variable to see if the autotests should be built, because when we just need the library to build an application we shouldn't waste electicity building the tests (and the Qt5::QML dependency).
> 
> 
> Diffs
> -----
> 
>   CMakeLists.txt 59917fa 
>   cmake/KF5I18NMacros.cmake 53ba812 
> 
> Diff: https://git.reviewboard.kde.org/r/126230/diff/
> 
> 
> Testing
> -------
> 
> 
> Thanks,
> 
> Boudewijn Rempt
> 
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kde-buildsystem/attachments/20151204/29007ee3/attachment-0001.html>