> 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.
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? - Kåre ----------------------------------------------------------- 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
