[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