> 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
>
>
_______________________________________________
Kde-buildsystem mailing list
[email protected]
https://mail.kde.org/mailman/listinfo/kde-buildsystem
