[bt-devel] PDFs and other object files in source tarballs

Jonathan Marsden jmarsden at fastmail.fm
Thu Nov 19 20:16:17 MST 2009


Earlier, I wrote:

> (b1) This is not really valid for the *.qm files, I think -- you'll
> need a working Qt development environment anyway, so you'll have an
> lrelease binary installed as a part of that, as I understand it, on
> all platforms.  What additional software is needed to convert .ts
> files into .qm files?  It doesn't seem to me that this is a
> particularly resource intensive process, either.  Is Qt lrelease
> broken on Windows?

Trying to stay positive, I just checked for the existence of lrelease, 
instead of just guessing that it exists, for all popular build 
platforms.  A sane-looking lrelease definitely exists in Linux, Windows 
and Mac Qt 4.4.x SDK installs (I opened up the .dmg file on a Windows PC 
to find the lrelease binary, I don't have a Mac available, so I can't 
actually run that binary).  I'm downloading the qt4 port onto an old 
(really old, Pentium III 500MHz or so!) FreeBSD machine as I type, so I 
can verify there is an lrelease in the Qt SDK there, also.

So: would it be both practical and appropriate to avoid storing *.qm 
files in the source tarballs and in svn, and to use lrelease on all 
platforms to create the *.qm files from the *.ts files at build time? 
The cmake work for doing this is apparently already in place.

As far as I can tell, all that should be needed is a one-line addition 
to ./build-debug.sh and ./build-release.sh, so that they each will run 
"make messages || exit 1" before running "make -j4 install || exit 1".

Speed of compiling the *.qm files seems very reasonable to me, totalling 
maybe 6 seconds or so on an old slow P4 machine, 3 seconds on a more 
recent quad core desktop machine.

Is there a still good reason for keeping *.qm files in the BibleTime 
source tarballs and svn tree?

Jonathan



More information about the bt-devel mailing list