Has something changed to the environment variable management lately?

classic Classic list List threaded Threaded
3 messages Options
Reply | Threaded
Open this post in threaded view
|

Has something changed to the environment variable management lately?

Jan Baeyens
Hello

I'm getting some strange behaviour with environment variables that used
to work just fine. I know it sounds crazy but .... It seems like the
environment variables have become "sticky" (in like the old value is
still available for some time after Sloeber updated it and then bang the
new value is there) and sometimes they do not get replaced at all.

In Sloeber nothing really has changed in this area for years so it looks
to me as if something happened in CDT in this area.

I realize that what I'm doing may be wrong/unsupported so here some 
highlights of the code I'm using

Help is appreciated

Jantje


getting the project configuration description

        ICProjectDescription prjCDesc =
CoreModel.getDefault().getProjectDescription(project);
         ICConfigurationDescription confDesc=
prjCDesc.getActiveConfiguration();

getting the environment manager

         IEnvironmentVariableManager envManager =
CCorePlugin.getDefault().getBuildEnvironmentManager();
         IContributedEnvironment contribEnv =
envManager.getContributedEnvironment();

removing all old values based on the beginning of the names

         IEnvironmentVariable[] CurVariables =
contribEnv.getVariables(confDesc);
         for (int i = (CurVariables.length - 1); i > 0; i--) {
             if (CurVariables[i].getName().startsWith(Const.ERASE_START)) {
contribEnv.removeVariable(CurVariables[i].getName(), confDesc);
             }
         }

Doing lots of these (the same key can be written on several times)

         IEnvironmentVariable var = new EnvironmentVariable(key,
makePathEnvironmentString(value));
         contribEnv.addVariable(var, confdesc);


Saving the data

CoreModel.getDefault().getProjectDescriptionManager().setProjectDescription(project,
prjCDesc, true, null);



_______________________________________________
cdt-dev mailing list
[hidden email]
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/cdt-dev
Reply | Threaded
Open this post in threaded view
|

Re: Has something changed to the environment variable management lately?

Jonah Graham
I don't know if anything has changed - certainly nothing in the last 6 months. I know some changes were made in environment handling over the years.

What this sounds like a much more likely case of a race condition on the project descriptions. I believe there are some known race conditions in this area, so perhaps it is that, or some code is holding a reference to the old project description for longer than it should be.

Sorry I can't be more helpful.

~~~
Jonah Graham
Kichwa Coders
www.kichwacoders.com


On Wed, 11 Mar 2020 at 20:50, Jan Baeyens <[hidden email]> wrote:
Hello

I'm getting some strange behaviour with environment variables that used
to work just fine. I know it sounds crazy but .... It seems like the
environment variables have become "sticky" (in like the old value is
still available for some time after Sloeber updated it and then bang the
new value is there) and sometimes they do not get replaced at all.

In Sloeber nothing really has changed in this area for years so it looks
to me as if something happened in CDT in this area.

I realize that what I'm doing may be wrong/unsupported so here some 
highlights of the code I'm using

Help is appreciated

Jantje


getting the project configuration description

        ICProjectDescription prjCDesc =
CoreModel.getDefault().getProjectDescription(project);
         ICConfigurationDescription confDesc=
prjCDesc.getActiveConfiguration();

getting the environment manager

         IEnvironmentVariableManager envManager =
CCorePlugin.getDefault().getBuildEnvironmentManager();
         IContributedEnvironment contribEnv =
envManager.getContributedEnvironment();

removing all old values based on the beginning of the names

         IEnvironmentVariable[] CurVariables =
contribEnv.getVariables(confDesc);
         for (int i = (CurVariables.length - 1); i > 0; i--) {
             if (CurVariables[i].getName().startsWith(Const.ERASE_START)) {
contribEnv.removeVariable(CurVariables[i].getName(), confDesc);
             }
         }

Doing lots of these (the same key can be written on several times)

         IEnvironmentVariable var = new EnvironmentVariable(key,
makePathEnvironmentString(value));
         contribEnv.addVariable(var, confdesc);


Saving the data

CoreModel.getDefault().getProjectDescriptionManager().setProjectDescription(project,
prjCDesc, true, null);



_______________________________________________
cdt-dev mailing list
[hidden email]
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/cdt-dev

_______________________________________________
cdt-dev mailing list
[hidden email]
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/cdt-dev
Reply | Threaded
Open this post in threaded view
|

Re: Has something changed to the environment variable management lately?

Jan Baeyens

Jonah

Thanks for the answer. Now I know this is unlikely a recent code change I'll dive into this some deeper.

As to future managed build: there is little to report but I'm still on it.
I've looked into the https://github.com/Kummallinen/cdt-new-managedbuild-prototype but I can't get heads or tail on it. Due to lots of new Sloeber issues I have very little time to focus on this right now.

Best regards

Jantje

Op 12/03/2020 om 3:04 schreef Jonah Graham:
I don't know if anything has changed - certainly nothing in the last 6 months. I know some changes were made in environment handling over the years.

What this sounds like a much more likely case of a race condition on the project descriptions. I believe there are some known race conditions in this area, so perhaps it is that, or some code is holding a reference to the old project description for longer than it should be.

Sorry I can't be more helpful.

~~~
Jonah Graham
Kichwa Coders
www.kichwacoders.com


On Wed, 11 Mar 2020 at 20:50, Jan Baeyens <[hidden email]> wrote:
Hello

I'm getting some strange behaviour with environment variables that used
to work just fine. I know it sounds crazy but .... It seems like the
environment variables have become "sticky" (in like the old value is
still available for some time after Sloeber updated it and then bang the
new value is there) and sometimes they do not get replaced at all.

In Sloeber nothing really has changed in this area for years so it looks
to me as if something happened in CDT in this area.

I realize that what I'm doing may be wrong/unsupported so here some 
highlights of the code I'm using

Help is appreciated

Jantje


getting the project configuration description

        ICProjectDescription prjCDesc =
CoreModel.getDefault().getProjectDescription(project);
         ICConfigurationDescription confDesc=
prjCDesc.getActiveConfiguration();

getting the environment manager

         IEnvironmentVariableManager envManager =
CCorePlugin.getDefault().getBuildEnvironmentManager();
         IContributedEnvironment contribEnv =
envManager.getContributedEnvironment();

removing all old values based on the beginning of the names

         IEnvironmentVariable[] CurVariables =
contribEnv.getVariables(confDesc);
         for (int i = (CurVariables.length - 1); i > 0; i--) {
             if (CurVariables[i].getName().startsWith(Const.ERASE_START)) {
contribEnv.removeVariable(CurVariables[i].getName(), confDesc);
             }
         }

Doing lots of these (the same key can be written on several times)

         IEnvironmentVariable var = new EnvironmentVariable(key,
makePathEnvironmentString(value));
         contribEnv.addVariable(var, confdesc);


Saving the data

CoreModel.getDefault().getProjectDescriptionManager().setProjectDescription(project,
prjCDesc, true, null);



_______________________________________________
cdt-dev mailing list
[hidden email]
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/cdt-dev

_______________________________________________
cdt-dev mailing list
[hidden email]
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/cdt-dev

_______________________________________________
cdt-dev mailing list
[hidden email]
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/cdt-dev