[sword-devel] BibleCS Installer

[DM Smith]

L.Allan-pbio wrote:
>> I was referring to the link I provided. I don't have enough 
>> experience or
>> accessible machines with earlier OSes. If our minimum target is Win98 
>> then
>> I think that HKCU is a fine target.
>>
>> Keep me posted on your findings and suggestions here.
>
> Separate email.

That email is really informative. Thanks!

>
>> I will be adding a page for choosing additional shortcuts:
>>    Desktop shortcut
>>    Quick Launch shortcut
>>    (could do others such as adding links to IE to the project's home 
>> page,
>> to make the project's home page IE's home page, .... But I am not 
>> inclined
>> at this time.)
>>
>> I am really surprised that MUI does not have built-in support for it. 
>> (At
>> least, I couldn't find it.)
>
> NSIS has an incredible forum for getting questions answered. Tremendous
> support.
> http://forums.winamp.com/forumdisplay.php?s=cb2e4e96ee9947ecf5dd456c7c676ce7&forumid=65 
>

I've only glanced here but may need to take a closer look.

>
> And a mature wiki
> http://nsis.sourceforge.net/Category:Code_Examples

I've been using this extensively.

>
>
> I've been doing quite a bit of experimenting with "custom pages", and 
> may be
> starting to understand them.

I see creating 2 custom pages:
1) Additional shortcuts
2) Module picker for "starter kit"
So, when you do understand them, I hope to "borrow" from you.
Again, I am trying to minimize the number of English strings so we could 
i18n the installer.

>
>
>>> * You've got an !include for WriteEnvStr.nsh, and a section for 
>>> that, but
>>> no Components page. Is that silently done then? Are you really 
>>> intending
>>> to write the SWORD_PATH environment variable?
>
>> Yes that is silent. I think it should always be set. But I could be
>> convinced otherwise.
>> (It is helpful to JSword which as a portable app, does not look at the
>> Windows' registry.)
>
>> I just heard about SWORD_PATH for the first time yesterday. What is it's
>> definition?
>> In JSword we have two notions of path. One is the set of directories 
>> that
>> contain mods.d and modules and the other is the one directory to 
>> which the
>> installer should write. For the latter, we allow one per install site
>> (e.g. stable, beta, local).
>> Does SWORD make this distinction?
>>
>> Should we also back this with a registry key.
>>
>> Should we allow the user to choose a location for the SWORD_PATH?
>
> It looks like your earlier SwordSetup.nis sets the SWORD_HOME environment
> variable rather than SWORD_PATH. Was this intended? 

Perhaps I meant SWORD_PATH. I thought I took SWORD_HOME from some 
earlier emails.

> On Win98, this re-writes
> autoexec.bat and suggests a reboot.

Same with Win95. This is intentional. But perhaps we should autodetect 
the OS and make the variable(s) optional.

>
> I'm an advocate of setting (and using) SWORD_PATH, but my impression 
> is that
> Troy G. may not be so inclined ...

Troy any input?

>
> (Also, the uninstaller references swicu20.dll and icudt34.dll. Did you
> intend icudt28l.dll ?)

These are artifacts of the executables I used for testing. I intend to 
use a variable for the ICU_DLL so I can update one location.
Right now the 1.5.8 rc1 uses icu28l.dll, but the svn trunk supplies 
icudt34.dll. This will need to be changed to match the final executable.

>
> Regarding the SWORD_PATH environment variable:
> In the SWMgr::findConfig method, there is a sequence of "detection 
> sniffing"
> going on to find the "modules" subdirectory and associated .conf 
> files. My
> understanding is that this applies mostly if the "modules" subdirectory
> isn't directly "under" where the executable sword.exe is running. The
> current "resolution" is (with proposed changes interspersed):
>
> + * 1a. (proposed .... not current) [BaseCrossWireDir]/mods.conf
> + * 1b. (proposed .... not current) 
> [BaseCrossWireDir]/resources/mods.conf
> + * 1c. (current) [BaseCrossWireDir]/SwordApiBasedApp/mods.conf
> + * 2a. (proposed .... not current) [BaseCrossWireDir]/mods.d
> + * 2b. (proposed .... not current) [BaseCrossWireDir]/resources/mods.d
> + * 2c. (current) [BaseCrossWireDir]/SwordApiBasedApp/mods.d
> + * 3. [SWORD_PATH environment variable]/mods.conf
> + * 4. [SWORD_PATH environment variable]/mods.d
> + * 5. [HOME environment variable]/mods.conf
> + * 6. [HOME environment variable]/mods.d
> + *
> + * Caveats: - I'm not familiar with Linux ... above assumes Windows
> + *          - Not familiar with how "augPaths" works
> + */
>
> A possible usage of SWORD_PATH may be to have a sword-api based app in a
> subdirectory without any modules "under" its installation 
> subdirectory. The
> modules would be "found" with SWORD_PATH. This is more in line with a
> "family of sword-api based apps" that share resources.

I'll take this into consideration and also look at SWMgr::findConfig.

>
>
> I'm only barely familiar with JSWORD .... is that your "home project"? 
> What
> does it use for an installer? The 2nd generation of the InVerse scripture
> memorization freeware was in Java, but the installation was tough .... 
> part
> of why I changed to MFC.
Yes, JSword is my "home project". It is a pure java implementation and 
interpretation (mostly complete) of the Sword API.
BibleDesktop is the GUI built on top of JSword. (You can get it here: 
http://www.crosswire.org/bibledesktop/download.html )
Since BibleDesktop is cross platform we have several installers and 
intend on some more.
1) Java WebStart for an Internet based install with dynamic update and 
offline execution once installed.
2) NSIS for windows install. And NSIS for a windows executable, which 
detects, and downloads if absent or inappropriate, the user's JRE, and 
then runs the java program. (This wrapper could dig into the windows 
registry and pass the location of mods.d) You can see our scripts here: 
http://www.crosswire.org/svn/jsword/trunk/bibledesktop/etc/installer
3) We also have zips which are appropriate for all architectures, but 
not very friendly.
4) On occasion we have MacOS dmg installer.
5) We hope to have RPM and DEB installers for linux soon.