[Glass] Can I assume GemStone 3.2.9 scripts and gsDevKit_home will NOT hardcode /opt/gemstone/product?

[Mariano Martinez Peck via Glass]

Thank you. I made some internal refactorings to my scripts because there
were some parts that were depending on a hardcoded
/opt/gemstone/product....    now they are fully independent, using the same
approach of Dale in gsDevKit_home using a symlink 'product'.

Best,

On Wed, Oct 21, 2015 at 7:39 PM, Dale Henrichs <
dale.henrichs at gemtalksystems.com> wrote:

>
>
> On 10/21/2015 03:25 PM, Mariano Martinez Peck wrote:
>
>
>
> On Wed, Oct 21, 2015 at 7:18 PM, Dale Henrichs via Glass <
> <glass at lists.gemtalksystems.com>glass at lists.gemtalksystems.com> wrote:
>
>> GsDevKit_home bases everything it does off GS_HOME ... so you _can_ have
>> multiple independent GsDevKit_home installations on the same machine and
>> they will not interfere with each other ....
>>
>> The product downloads are stashed in
>> $GS_HOME/shared/downloads/products/<product-name>
>>
>> The stones are stashed in $GS_HOME/server/stones/<stone-name>.
>>
>> There is a symbolic link in the stone directory:
>> $GS_HOME/server/stones/<stone-name>/product that points to the relevant
>> product in $GS_HOME/shared/downloads/products and GEMSTONE is defined as:
>>
>>   export GEMSTONE=$GS_HOME/server/stones/<stone-name>/product
>>
>>
> That's perfect.
> And what about all $GEMSTONE/bin   , $GEMSTONE/upgrade   ,
>  $GEMSTONE/seaside/bin  etc
> as long as I do not source defSeaside (which I do not do it) it seems I am
> safe. Correct?
>
> If true, do you know if the same assumption could be taken for 3.1.0.6 ?
>
>
> Well the normal operating mode is that GEMSTONE is not part of you
> standard environment ... only GS_HOME should/needs to be defined when you
> use GsDevKit_home ... the GEMSTONE env var is defined dynamically in the
> scripts based on the stoneName (which is another reason why startNetldi and
> stopNetldi take the stone name as an arg ... so GsDevKit_home can know what
> $GEMSTONE/bin ... etc. to use) ...
>
> In GsDevKit_home, there is a defStone.env that does what defSeaside used
> to do and the only time that you need to use it is when you are going to
> run topaz ... I probably should create a wrapper script for topaz so that
> even then you don't need to get GEMSTONE into your env or worse
> GEMSTONE/bin into your path:)
>
> GsDevKit_home treats every GemStone version the same ... only GS_HOME
> needs to be set ...
>
> Dale
>



-- 
Mariano
http://marianopeck.wordpress.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.gemtalksystems.com/mailman/private/glass/attachments/20151023/027a4428/attachment.html>