build window weirdness & Env vars

[jporkkahtc]

bug #1: Workspace env-vars do not take effect in the build window automatically.
You can make it happen by typing "exit", causing Slick to restart the build window.
Slick oughta do this.


bug #2: When "Set CD when switching buffers" is ON and auto-restore workspace files is on, then when switching workspaces the BUILD window goes nuts.
Apparently as each file is loaded Slick issues a "CD" command in the build window.
The really weird thing though is that it seems to wait until you activate the build window again before it really does it --- because it then seems to slowly run each "C: & cd C:\foo\bar" command one at a time.
The user experience here is really bad as the build window seems to take on a life of its own and it isn't at all clear what the heck it is doing.

[Clark]

Bug #1 close and reopen the workspace

Bug #2 I think we can fix this.

[jporkkahtc]

#1: No, that doesn't do it.
The only way I've found is to either restart Slickedit, or type "exit" in the build window.

Another thing, once I close the workspace, typing "exit" in the build window isn't good enough -- the new build window retains the variables from the most recent workspace.

Hmmm ...  env vars seem only additive.

WKS1: set WK1=ABC
WKS1: set WKALL=ONE

WKS2: set WK2=DEF
WKS2: set WKALL=TWO

Open WKS1, "exit" the build window and start it.
Open WKS2, "exit" the build window and start it.
In build type "set WK"
You will see
WK1=ABC
WK2=DEF
WKALL=TWO


Maybe Slick oughta retain a copy of its original env vars, then when switching workspaces it should reset its environment to that before adding the workspace env vars.

[Clark]

There is save/restore code for only some env vars at the moment.

Opening a workspace is supposed to set the environment variables we will look into this.

[Clark]

Have you tried setting your environment variables in the Open tab of project properties (set name=value)?

Workspace environment variables are currently only for vsbuild.exe. No good work around at the moment without killing performance (which is what it does for our workspaces here >=40 envvars). Maybe we can come up with some high performance way to set them. Then it won't matter.

[jporkkahtc]

Why does setting 40 env vars kill performance?
Doesn't seem like that is nearly enough to be a problem.


Does the number of variables matter other than when switching workspaces?




How are they only for vsbuild?
They show up in the build window, and I assume they would affect any of the tools run from a project.




I've not tried the Open tab of project because I would have to set these variables for all of the projects in the workspace. (And I didn't think of running commands - I was thinking env-vars).
Setting them in workspace seemed like the right place.
Are project specific env-vars more efficient somehow?

[Clark]

This area need a lot of work. Something completely new needs to be done.

We could add a hack def var off by default to set them.

[Clark]

Beta 3 will support setting environment workspace variables in the build window if it's already running. We came up with a way to optimize setting the environment variables.

This is good enough for now.

There could still be a lot of work done in this area. Some environment variables are only for vsbuild.exe. Others are only for the IDE (used by aliases). Also, environment variables are never removed (originally/startup environment never restored).

Another change for consistency: If the "Value" attribute contains a string of length 0, the environment variable is removed. At least this way you can manually remove environment variables.