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

Sat Dec 5 20:23:12 UTC 2015

> On Dec. 4, 2015, 10:35 a.m., 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.
> 
> Chusslove Illich wrote:
>     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.
> 
> Aleix Pol Gonzalez wrote:
>     @Chusslove, that might make it harder for people to port applications to Windows though. (Or Android for that matter)
>     
>     Maybe we can find an in-between compromise solution? In the end building translations is something that only happens when you're about to release.
> 
> Kåre Särs wrote:
>     I did a compile Kate on Windows exercise this summer and fall (hoping I will get to the installer soon :) I was expecting _some_ hurdles but I was shocked about how hard it was to compile KDE Frameworks 5 on Windows without using emerge. This basically means that big parts of frameworks just was not a realistic alternative for third-party Windows applications. With changes that have flown in during this fall the building of frameworks on Windows has become _much_ easier and is soon a real alternative for Windows Qt projects.
>     
>     The gettext and python dependencies are probably the biggest hurdles. My build script uses a trick inherited from emerge that just downloads a pre-built binary package for the gettext tools and I had to rename some of the include directories found in the Python installation because they clashed with the rest of the build. Requiring python and downloading random packages from SF is probably not something that any of my colleges at work would like to add to their Qt projects.
>     
>     Translations are really important and needs to be taken care of. I would like it to be possible to split out the utilities somehow so that I could compile the application without installing the utilities needed for the compilation. The parts requiring Python/Gettext would be like CMake a separate tool and not like Autotools a part of the package.
>     
>     @Chusslove: This patch only disables the tools. What would it take to split the tools out into a separate build?
> 
> Chusslove Illich wrote:
>     If you don't have Gettext tools and Python, then you cannot properly build translation files, of KI18n and other packages using it, no matter how you do it.
>     
>     But I don't follow what's going on there for Windows, so better not bother anyone explaining it. Then, maybe have an explicit option to switch to a no-op version of the ki18n_install macro, say:
>     
>       option(DROP_TRANSLATION_BUILDS "Replace CMake macros for building and installing translation files with no-op macros" OFF)
> 
> Boudewijn Rempt wrote:
>     I don't really know what "scripted translations" are, but it sounds like a runtime thing for an application, so I don't get how removing a build-time dependency breaks that. I know I must be missing something, because why should I want to build translation files? Why can't I use the translations files that someone else has already built for the few frameworks that we use? I mean, when you install a framework on Linux through your distribution's package manager, that doesn't run gettext and python to do stuff, does it?
> 
> Chusslove Illich wrote:
>     I don't want to go into such considerations. From my point of view, if one is building software that uses Gettext-based translations, one should make sure normal Gettext setup is available. Similar for Python.
>     
>     Nevertheless, I offered to introduce the funny possibility to disable the build system support for translation files, via an explicit CMake option as above. Is there a problem with this solution?

If a dependency is optional, it needs to be defined as such: here's an example:
```
set_package_properties(Qca-qt5-ossl PROPERTIES
         PURPOSE "Runtime-only dependency on the OSSL plugin of QCA for authentication to work properly"
         TYPE RUNTIME
)
```

Lack of runtime dependencies shouldn't hold the build though.

- Aleix

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

On Dec. 4, 2015, 1:17 a.m., Boudewijn Rempt wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/126230/
> -----------------------------------------------------------
> 
> (Updated Dec. 4, 2015, 1:17 a.m.)
> 
> 
> 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/20151205/dd966c70/attachment-0001.html>