Smalltalk › Gemtalk › GLASS

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

_‹ Previous Topic Next Topic _›

Classic

List

Threaded

5 messages Options

GLASS mailing list

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

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,

Mariano
http://marianopeck.wordpress.com

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

GLASS mailing list

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

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,

--

Mariano
http://marianopeck.wordpress.com
_______________________________________________
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

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

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,

--

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

Mariano
http://marianopeck.wordpress.com

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

GLASS mailing list

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

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

GLASS mailing list

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

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

Mariano
http://marianopeck.wordpress.com

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