[sword-devel] BibleTime Windows and Mac packages
jerickson314 at users.sourceforge.net
Sat Apr 18 09:45:55 MST 2009
On Saturday 18 April 2009 9:23:46 am Manfred Bergmann wrote:
> Am 18.04.2009 um 13:48 schrieb Jeremy Erickson:
> > In BibleMemorizer, I followed the steps described in the document for
> > including frameworks in the bundle, except that I wrote a script
> > (osx-bundle-prepare.pl) that automated the process. The script is
> > very
> > BibleMemorizer specific, but you could modify it fairly easily for
> > BibleTime.
> > Feel free to get it from the latest source distribution of
> > BibleMemorizer and
> > reuse it with modifications.
> We do too place frameworks in the application bundle in MacSword.
> What does this script do?
The script has several stages:
1.) It updates plugin configuration files so that QLibrary can find them on
Mac OS X. (This is completely BibleMemorizer-specific)
2.) It copies BibleMemorizer plugins from the build directory into the bundle.
(This is also BibleMemorizer-specific)
3.) It determines what frameworks BibleMemorizer uses and copies them
from /Library/Frameworks into the bundle. (This is generally useful if
modified to look at the right executable).
4.) It performs relocation using install_name_tool to update the
BibleMemorizer executable, the Sword plugin (which uses BT classes that
require Qt), and the frameworks it just copied, so that all use the Qt inside
the bundle. (This is also generally useful if updated to refer to the right
executable and/or plugins.)
The last two steps are just the steps from the doc for including a "private
framework", as DM noted. It's just that they are quite tedious to do by hand
and must be done on every rebuild, so I scripted them. It seems Qt's new
deployment tool in 4.5 does the same thing. This was not available when I
last did a BibleMemorizer release.
I'm guessing that when Greg did the private frameworks improperly, he missed
some or all of stage 4.
I do recommend the private framework approach, though, as it allows the
drag-and-drop installation. Technically we could save some RAM and disk
space on the user's system by using shared frameworks, but the extra hassle
on the user's part and required use of installers would probably not be worth
More information about the sword-devel