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@crosswire.org
http://www.crosswire.org/mailman/listinfo/sword-devel
Instructions to unsubscribe/change your settings at above page
