[sword-devel] BibleCS Installer: SWORD_PATH

[DM Smith]

My thoughts:
I think we would want the owners of BibleCS to buy off on these changes 
to the location of mods.d.
Most users don't care to learn about SWORD_PATH. They should not have 
to. They should not be told about it.
Those that do care probably are developers, and they can handle it 
changing out from under them.
I agree that If SWORD_PATH is sane, then it should be left alone and if 
not, then it should be either deleted or fixed.

I did some testing of various configurations and it seems that if 
SWORD_PATH points to a real directory that does not have a mods.d then 
the InstallMgr will break. (It might not be a problem with the final 
production build. I am using a beta version.)

I'm working under the assumption that if it is bad then BibleCS 
installer is not going to go hunting and is just going to set it to its 
install directory.

SWORD_PATH is genuinely useful to applications that don't have direct 
access to the Window's registry.
(That is currently JSword has no idea where mods.d is unless it is 
C:\Program Files\CrossWire\The SWORD Project\mods.d)

A difficulty in using SWORD_PATH is that an installer that is a starter 
pack has to be written in such a way to install its modules into the 
location pointed to by SWORD_PATH or what SWORD_PATH should become. 
(This should be true of the LCDBible install, if mods.d does exist under 
"The SWORD Project" and SWORD_PATH is not set.)


L.Allan-pbio wrote:
> 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.
>
>
> _______________________________________________
> sword-devel mailing list: sword-devel at crosswire.org
> http://www.crosswire.org/mailman/listinfo/sword-devel
> Instructions to unsubscribe/change your settings at above page
>