Update your copy of extra-cmake-modules

Aurélien Gâteau agateau at kde.org
Sat Apr 26 08:45:12 UTC 2014


Alex Merry wrote:

> On 21/04/14 16:26, šumski wrote:
>> On Friday 18 of April 2014 10:37:50 Aurélien Gâteau wrote:
>> ...
>>> I made it that way intentionally because I consider it bad to have
>>> different code generated depending on whether you have the framework is
>>> built from a release tarball or from git.
>>>
>>> I understand this means more build dependencies for packagers, but I
>>> don't see any other way.
>> 
>> Understood. Wrt the packaging, that can be more or less bypassed (and
>> i've done so already with openSUSE Qt5 packages), but i was also curious
>> about additional dependencies in general. E.g. with KArchive, previously
>> only QtCore was needed to get it built. Now people will need to build
>> e.g. qtdeclarative and qtwebkit to get qttools, which is now hard
>> requirement for KArchive (note that i haven't checked is
>> ECMCreateQmFromPoFiles added specifically to KArchive, but this is
>> applied to any such Framework).
> 
> I guess the ideal solution would be to integrate the po->ts conversion
> into the translation workflow (ie: a job for scripty). That way, qttools
> is not needed at build time.
> 
> The build/install process for the l10n modules should still do the
> conversion, of course, otherwise translators couldn't do their testing
> properly. But we should ship .ts files with frameworks instead of .po
> files.

Sorry, I am a bit late on this thread. Alex and I discussed this during the 
KF5 sprint.

Shipping .ts would not be good enough since we need to turn them into .qm, 
and doing so requires lrelease which comes with linguist.

For me the short-term fix is for packagers to split the linguist package so 
that command line tools (lconvert, lupdate, lrelease and Qt5LinguistTools* 
cmake files) and linguist are in separate packages. The command line tools 
could then be used as a build dependency without bringing too much with 
them.

The long-term fix would be to get this split upstream in Qt, but that 
requires some refactoring because linguist and the tools share some code 
statically.

Aurélien



More information about the Kde-frameworks-devel mailing list