[sword-devel] BibleCS Installer: SWORD_PATH

[L.Allan-pbio]

Regarding SWORD_PATH issues (split from general BibleCS Installer thread to 
be focused on this issue alone) :

DM Smith wrote:
>>> I didn't think about overwriting. I'll see about adding a check to see 
>>> if it is currently defined and pointing to an existing directory. If it 
>>> is not then I think it should be set.
>>>
>>> This should be in a separate nsh file so all SWORD family applications 
>>> can use it.

Lynn A wrote:
>> I'm interested in seeing what you come up with.

Based on the way SWMgr::findConfig currently works, I would advocate a 
"preferred practice for family-of-apps" to coherently handle SWORD_PATH ... 
something like the following:

*** If SWORD_PATH is defined:
- Check if there is both an existing mods.d or mods.conf subdirectory under 
SWORD_PATH, and also a modules subdirectory under the SWORD_PATH directory. 
That would indicate a good probability of a "sane" SWORD_PATH setup. If so, 
leave SWORD_PATH alone. (May be sufficient to just have mods.d or mods.conf)

- If SWORD_PATH exists, but doesn't seem "sane", look in the $INSTDIR and 
see if there is a mods.d / mods.conf  "under it" or as a "sibling". If so, 
suggest/offer to set SWORD_PATH to this directory.
C:\Program Files\CrossWire\The SWORD Project\mods.d
C:\Program Files\CrossWire\The SWORD Project\modules

- If SWORD_PATH exists, but doesn't seem "sane", look in the parent of 
$INSTDIR and see if there is a mods.d / mods.conf. If so, suggest/offer to 
set SWORD_PATH to this directory.
C:\Program Files\CrossWire\mods.d
C:\Program Files\CrossWire\modules

- If SWORD_PATH exists, but doesn't seem "sane", look in a "sibling" of 
$INSTDIR (by convention ..\resources) and see if there is a mods.d / 
mods.conf. If so, suggest/offer to set SWORD_PATH to this directory.
C:\Program Files\CrossWire\resources\mods.d
C:\Program Files\CrossWire\resources\modules

*** If this is the first installation (no previous installations) and 
SWORD_PATH isn't set, set the SWORD_PATH to the parent of $INSTDIR, so that 
the default would be:
C:\Program Files\CrossWire\mods.d
... or a "sibling" of $INSTDIR ....
C:\Program Files\CrossWire\resources\mods.d
 (create this directory with SetOutPath)

*** If SWORD_PATH not defined and there has been a previous installation
- Check "sanity" of mods.d / mods.conf, and if they seem ok offer/suggest 
setting SWORD_PATH to the parent of mods.d / mods.conf ... which with 
current practice, would be:
C:\Program Files\CrossWire\The SWORD Project

The issue involved is avoiding a proliferation of indepedent modules being 
installed, rather than sharing the modules (each app like LcdBible and 
JSWord would tend to have their own redundant resources separate from 
BibleCS).

With the above, it would be practical and transparent to have:
C:\Program Files\CrossWire\The SWORD Project\mods.d
C:\Program Files\CrossWire\LcdBible
C:\Program Files\CrossWire\JSword

If BibleCS is installed first without SWORD_PATH being defined (as done by 
the current 1.5.6 installers and earlier), and has some modules installed 
"under" it, then the current "preferred practice" seems to be install other 
"family apps" in the $INSTDIR of BibleCS ... which seems flawed and 
avoidable.

I've submitted a patch for SWMgr::findConfig, but don't expect it to be 
included in 1.5.8. My speculation is that this is the last point in time 
that it is feasibly realistic to significantly alter past practice such that 
a "family of sibling apps can play nice and share among themselves". Once 
1.5.8 is released, the "concrete" is that much more "hardened".

(something I'm unclear about .... does JSword use the C++ api in some manner 
of "binding", or does it have an independent "reversed engineered" api 
written in Java?)

*** Perhaps detect and warn about redundant resources .... This would be the 
case if SWORD_PATH was defined (with "sane" mods.d) and there was also a 
previous installation with "sane" mods.d "under" its $INSTDIR, but didn't 
agree with SWORD_PATH. Something like:
C:\Program Files\CrossWire\The SWORD Project\mods.d
X:\Reference\MySwordPath\mods.d

Perhaps I am overly concerned (bordering on argumentative if not stident on 
this issue) .... disk space is plentiful. Who cares? Let's get it done and 
out the door and maybe improve the next go-around.

However, redundant resources (probably?) create problems for the 
InstallManager (and internationalization?), uninstallers, and potential 
end-user confusion ("I thought I installed xyz, but it isn't showing up." or 
"I tried to update abc, but I'm still seeing the old one.").

There is a place for having "un-sync'ed" SWORD_PATH and $INSTDIR for 
developer experimentation and testing, but sharing seems otherwise advised, 
and worth some effort on our part.

My impression is that the CrossWire sword-api is intended to provide a 
developer environment of "you build the app, we supply the api." This can 
and should extend to the installers being aware of and facilitating 
"siblings". I advocate that the BibleCS installer can and should be a 
"template" that other "siblings" can "clone" from. Preferrably for 1.5.8.

Perhaps this isn't that applicable, but software is supposed to be highly 
cohesive and loosely coupled. But within an intended "family of sibling 
apps", there should perhaps be high cohesion and relatively tight coupling. 
I understand that BibleCS is the "senior elder sibling" and r.h.i.p. 
(especially compared to LcdBible), but I appreciate your willingness to 
"wrestle" with the SWORD_PATH issues. And your patience.

My impression is that you are the person responsible for the JSword 
installer. You are probably already doing this, but try to maximize thinking 
in terms of how the BibleCS installer can be a template for the JSword 
installer to clone from.

The prototype LcdBible installer has much of this code already implemented, 
so it is doable. NSIS isn't all that good for implementing complicated 
if-then-else testing, but there is logiclib to avoid all the GoTo's and 
jumps. Testing is tedious and error prone to cover all the permutations, 
unfortunately.

(Mea culpa ... my tendency is to not think about internationalization issues 
because I've never had to deal with them .... the above may need enough 
explanation to cause problems???)

Which brings up the issue .... are the InstallManager and icu##.dll shared 
resources? These are BIG files and redundancy is perhaps less desirable with 
them than resource modules. I suppose it doesn't matter much with CD 
installations .... just copy an entire directory structure with no 
installer, and don't worry about defining SWORD_PATH.

Another issue (sorry) .... my understanding is that the location of the 
modules subdirectory which actually has the content is stictly defined by 
the associated mods.d file. The xyz.conf for the xyz resource has an entry 
for DataPath= that actually determines where the sword-api will find the 
content and offset/length index files. Based on the .conf files I've looked 
at, the convention seems to be that the resources will be in a "sibling" 
directory named modules that is located at [Mods_d_directory]..\modules. I 
suppose it would be possible (although probably not advisable) to have the 
resources as "children" of the mods.d directory. But too late for that, even 
if there were technical advantages.