> On Dec. 4, 2015, 9: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)
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? - Boudewijn ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/126230/#review89109 ----------------------------------------------------------- On Dec. 4, 2015, 12: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, 12: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-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
