[bt-devel] BibleCS / BibleTime on Windows

Gary Holmlund gary.holmlund at gmail.com
Wed Feb 10 07:23:47 MST 2010


I did run mgrtest and it just confirmed that the facts that I had found 
by debugging sword. We need to unset the SWORD_PATH for BT to work 
correctly.

I checked in a fix for the SWORD_PATH issue. With this fix the 
SWORD_PATH env variable  is unset inside of BT and the path is saved so 
it could be used later. With this change BT works correctly when the 
variable has been set. It does not automatically use the path obtained 
from SWORD_PATH, but the user could add the path manually. I wanted to 
get this in for the beta release today.

I will continue to work on a change to the Bookshelf Folders dialog so 
that the SWORD_PATH will automatically be used unless the user disables 
it. I will publish a bazaar branch for this when I get it ready. We can 
decide if we like this change then.

Gary

Troy A. Griffitts wrote:
> A few quick comments.
>
> May I stress again that sword/tests/mgrtest will be an invaluable tool 
> to help you work through the best configuration.
>
> It should print out step by step every place the engine is looking and 
> where it finally resolves it's configuration.
>
> If you compile it for windows and place mgrtest.exe in the same 
> directory as bibletime.exe and run mgrtest.exe, you'll see how the 
> engine is configured and it should be the same for bibletime.
>
> sword 1.5 and 1.6 cannot share locales.
>
> if a DataPath does not contain a mods.d/ folder, it will not be 
> considered valid.  sword.conf MUST contain a valid DataPath or it will 
> not be used.
>
> Hope this helps,
>
> Troy
>
> Gary Holmlund wrote:
>> Gary Holmlund wrote:
>>> Eeli Kaikkonen wrote:
>>>> On Mon, 1 Feb 2010, Eeli Kaikkonen wrote:
>>>>  
>>>>> I may have found the Windows problem, too. The search for the 
>>>>> modules is
>>>>> stopped if there's mods.d directory in $SWORD_PATH. We use that env
>>>>> variable if it's found. Therefore, if the BibleCS is installed, the
>>>>> engine doesn't find modules installed elsewhere. Gary, am I right?
>>>>>
>>>>> Doesn't this also destroy the idea of adding e.g. CD or USB stick
>>>>> locations, because they can't be used if $SWORD_PATH is used? Does 
>>>>> the
>>>>> engine really work this way?
>>>>>     
>>>>
>>>> No, I don't know if it really works this way. I'll try to find it out
>>>> but appreciate any help, especially on the Windows port.
>>>>
>>>> The locale problem seems to have a solution. The engine documentation
>>>> isn't quite correct, it doesn't mention the LocalePath in the
>>>> sword.conf. I found it in our own code. It just isn't used on Linux,
>>>> Gary has written it for Windows. I hope it works there.
>>>>   
>>> Eeli,
>>>
>>> Sorry I have not had much time this weekend to look at this. I am 
>>> getting ready to go to work so I will try to get a short answer now 
>>> and spend more time on this issue tonight.
>>>
>>> We have a unique requirement on Windows. There is no standard 
>>> location for sword and its locales. We include the sword locales in 
>>> our installation package (c:\Program 
>>> Files\BibleTime\share\sword\locales.d).
>>>
>>> To make sword find this we must control the sword startup. During Bt 
>>> startup we set the current working directory to $HOME/Sword where 
>>> $HOME is defined to be:
>>>
>>> APPDATA=C:\Documents and Settings\<username>\Application Data  (on 
>>> windows xp)
>>>
>>> We have a sword.conf there which defines the location of locales.d. 
>>> The $HOME/Sword/sword.conf should look like this:
>>>
>>> [Install]
>>> DataPath=C:\Documents and Settings\All Users\Application Data\Sword
>>> LocalePath=C:\Program Files\BibleTime\share\sword
>>>
>>> With this BibleTime should look for modules at $HOME/Sword and at 
>>> the "DataPath" above. If another directory is added using our 
>>> bookshelf manage, it will appear as an AugmentPath in the 
>>> $HOME/Sword/sword.conf file.
>>>
>>> This is how it is supposed to work. I will look further at this 
>>> tonight.
>>>
>>> Gary
>> I have BibleCS installed and I have stepped through the 
>> initialization of sword during the startup of BibleTime. One thing is 
>> clear. Sword is hard to understand. :)
>>
>> I can see that with the SWORD_PATH that is set by BibleCS, Bt will 
>> find the locales information under the BibleCS directories and 
>> BibleCS seems to be sword 1.5.11 versus Bt using 1.6.0. I don't know 
>> how much trouble this might cause.
>>
>> The SWORD_PATH also is blocking any module paths beyond the 
>> $HOME/Sword directory.
>>
>> And in the debug version, but not the release version, sword  
>> crashes  with a  bad iterator while looping  through the modules, 
>> some of which come from BibleCS and other are installed in $HOME/Sword/
>>
>> My best suggestion is to unset SWORD_PATH inside of Bt at startup. 
>> Sword won't find it then and both BibleCS and BibleTime will run, but 
>> they won't share modules. Perhaps we can get the value of SWORD_PATH 
>> before unsetting it and use it as an augment pah and still share 
>> modules?
>>
>> Anyone else have a better suggestion?
>>
>> Gary
>>




More information about the bt-devel mailing list