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: [email protected]
http://www.crosswire.org/mailman/listinfo/sword-devel
Instructions to unsubscribe/change your settings at above page
_______________________________________________
sword-devel mailing list: [email protected]
http://www.crosswire.org/mailman/listinfo/sword-devel
Instructions to unsubscribe/change your settings at above page
