Changing environment variables when changing workspaces?

[warnerrs]

Is there some way to change environment variables when changing workspaces? More specifically, is there some way to use linux shell scripts to do that task?

My work flow requires certain environment variables to be set for certain scripts to work properly. I source the environment setup script before beginning my work.  Then I start SlickEdit which inherits those environment variables. The compile and execute commands which I have Slick configured to use depend on those Environment variables.

So, going to Project->All Workspaces->something_else.vpw, doesn't really work well.  It is useful for quickly going to a different workspace to browse some code, but I can't compile or execute, so it's not useful for changing workspaces to actually work.

I imagine a macro could hook into the changing of workspaces, but is it possible to source a csh script, or use a unix "module load" and have that manipulate Slick's environment? I think the brute force solution would be to start a shell, source the desired script, dump the variables to STDOUT with env, capture that and parse it, and then change SlickEdit's Environment variables.  Is there a chance someone has already done this?

Thanks,
-Ryan

[hs2]

You can manage workspace specific env. vars with 'Project>Workspace Properties: Environment button'.
That's the easiest, officially supported way.
So better double check if you really need a diff. solution, which is also possible with some macro support.
(I'm using an internal Slick callback invoked when opening a project for setting up certain project specific build env.s and I'll post an example if needed.)
HS2

[warnerrs]

Ah. Ok. I think I can work with this.  I use a wrapper script to start SE anyway.  I can scrape the environment variables in that script and update the .vpw file with the current values. A workspace switch from the GUI won't do that, but will just load what was last saved in the .vpw. This preserves SE's environment management mechanism.

Thanks.

[hs2]

Or vice versa: manage your env.vars with the SE workspace props. They are 'exported' by SE to the build shell.
Well, except your script derives/generates the env.vars somehow instead of just setting them..
HS2

[warnerrs]

The environment scripts that manage the vars are part of our corporate methodology, and only some of us use SE, so we can't use SE as the mechanism to manage the vars. That would be sub-optimal anyway, as manually setting env vars is horrible compared to using unix modules ( http://modules.sourceforge.net/ ) to do it for you.

[hs2]

Ok - that's what I was thinking..
Alternatively you could hook the '_prjopen_' SE callback e.g. writing a '_prjopen_warnerrs' macro which is called when changing a project (which is a build unit usually).
There are some global vars to figure out the active workspace, project, build type etc. to trigger the right actions (incl. set_env, get_env) on the right workspace::project(build type) e.g. _workspace_filename, _project_name, gActiveConfigName.
Good luck, HS2

[warnerrs]

Does that hook get called early enough that I could just update variable definitions in the vpw file? Or is it too late for that, and I need to use the set_env function?

[hs2]

The workspace containing the projects is already loaded. You have to use set_env to setup your build env. accordingly. The hook is called early enough so that the build shell inherits the prepared env. You have all SE macro possibilities e.g. reading config files or whatever to do what's needed.
Good luck, HS2