[Glass] Throw away all 32bit code from the installation code ...

[Dale Henrichs via Glass]

On 9/8/15 5:14 PM, Dale Henrichs wrote:
>
>
> On 09/08/2015 02:02 PM, itlists at schrievkrom.de wrote:
>>
>> Then on top of all that the tODE infrastructure (or gsDevKitHome)
>> installation can be used - what ever someone likes to implement. The
>> customer can then decide if he prefers the additional tools or if he
>> prefers a more simple installation.
> There are indeed multiple levels in the current gsDevKitHome 
> architecture and tODE is not required for all of the scripts ... my 
> take away from this is that I should consider perhaps one more 
> segmentation of the scripts/functionality that makes it the 
> distinction between scripts that are based on tODE and those that are 
> not ...

Just to sketch out an idea in more detail ... please let me know if I am 
on the right track from your perspective ...

So from the very top level the segmentation can be emphasized by having 
a set of options for the installServer script that allow you to 
determine the type of stone you want ([-b|-g|-t] options):

USAGE: installServer [-h] [-f] [-b|-g|-t] [-s <snapshot-file-path>] 
<stone-name> <gemstone-version>
...
OPTIONS
   -b
      create a base GemStone stone - use $GEMSTONE/bin/extent0.dbf. No 
additional
      code loaded and no tODE client created.
   -h
      display help
   -f
      force creation of stone and tode image
   -g
      create a GLASS/GsDevKit stone - use 
$GEMSTONE/bin/extent0.seaside.dbf. Update
      repository using gsUpgrader and no tODE client created
   -s <snapshot-file-path>
      Path to snapshot file used to create stone. Path may be a relative 
file path.
   -t
      [DEFAULT] create a tODE stone - use 
$GEMSTONE/bin/extent0.seaside.dbf. Update
      repository using gsUpgrader, then install tODE and create a tODE 
client.

The same set of options ([-b|-g|-t]) would be available for the 
createStone script. The start* and stop* can be used for all stones .

Does this make sense?

Dale