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

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
5 messages Options
Reply | Threaded
Open this post in threaded view
|

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

GLASS mailing list
Hi guys, 

I did a quick check and it seems to be the case. But just in case...

 While I can accept some bugs or mis-hardcoded places, let me ask: it is ok to assume that GemStone 3.2.9 and gsDevKit_home DO NOT rely on a hardcoded /opt/gemstone/product but on $GEMSTONE ?

Thanks in advance,  

--

_______________________________________________
Glass mailing list
[hidden email]
http://lists.gemtalksystems.com/mailman/listinfo/glass
Reply | Threaded
Open this post in threaded view
|

Re: Can I assume GemStone 3.2.9 scripts and gsDevKit_home will NOT hardcode /opt/gemstone/product?

GLASS mailing list
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

Dale

On 10/21/2015 03:09 PM, Mariano Martinez Peck via Glass wrote:
Hi guys, 

I did a quick check and it seems to be the case. But just in case...

 While I can accept some bugs or mis-hardcoded places, let me ask: it is ok to assume that GemStone 3.2.9 and gsDevKit_home DO NOT rely on a hardcoded /opt/gemstone/product but on $GEMSTONE ?

Thanks in advance,  

--


_______________________________________________
Glass mailing list
[hidden email]
http://lists.gemtalksystems.com/mailman/listinfo/glass


_______________________________________________
Glass mailing list
[hidden email]
http://lists.gemtalksystems.com/mailman/listinfo/glass
Reply | Threaded
Open this post in threaded view
|

Re: Can I assume GemStone 3.2.9 scripts and gsDevKit_home will NOT hardcode /opt/gemstone/product?

GLASS mailing list


On Wed, Oct 21, 2015 at 7:18 PM, Dale Henrichs via Glass <[hidden email]> 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 ?

 
Dale


On 10/21/2015 03:09 PM, Mariano Martinez Peck via Glass wrote:
Hi guys, 

I did a quick check and it seems to be the case. But just in case...

 While I can accept some bugs or mis-hardcoded places, let me ask: it is ok to assume that GemStone 3.2.9 and gsDevKit_home DO NOT rely on a hardcoded /opt/gemstone/product but on $GEMSTONE ?

Thanks in advance,  

--


_______________________________________________
Glass mailing list
[hidden email]
http://lists.gemtalksystems.com/mailman/listinfo/glass


_______________________________________________
Glass mailing list
[hidden email]
http://lists.gemtalksystems.com/mailman/listinfo/glass




--

_______________________________________________
Glass mailing list
[hidden email]
http://lists.gemtalksystems.com/mailman/listinfo/glass
Reply | Threaded
Open this post in threaded view
|

Re: Can I assume GemStone 3.2.9 scripts and gsDevKit_home will NOT hardcode /opt/gemstone/product?

GLASS mailing list


On 10/21/2015 03:25 PM, Mariano Martinez Peck wrote:


On Wed, Oct 21, 2015 at 7:18 PM, Dale Henrichs via Glass <[hidden email]> 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

_______________________________________________
Glass mailing list
[hidden email]
http://lists.gemtalksystems.com/mailman/listinfo/glass
Reply | Threaded
Open this post in threaded view
|

Re: Can I assume GemStone 3.2.9 scripts and gsDevKit_home will NOT hardcode /opt/gemstone/product?

GLASS mailing list
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 <[hidden email]> 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 <[hidden email][hidden email]> 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



--

_______________________________________________
Glass mailing list
[hidden email]
http://lists.gemtalksystems.com/mailman/listinfo/glass