Bug 337629 - Setting environment variables using shell functions or scripts
Summary: Setting environment variables using shell functions or scripts
Status: NEW
Alias: None
Product: CDT
Classification: Tools
Component: cdt-build-managed (show other bugs)
Version: 8.0   Edit
Hardware: PC Linux
: P3 enhancement with 2 votes (vote)
Target Milestone: ---   Edit
Assignee: Project Inbox CLA
QA Contact: Jonah Graham CLA
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2011-02-18 21:28 EST by Roland Schulz CLA
Modified: 2020-09-04 15:18 EDT (History)
8 users (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Roland Schulz CLA 2011-02-18 21:28:04 EST
We would like to use modules.sf.net with CDT. Modules allows to set the environment based on pre configured module files. It would be nice if CDT had some convenient way to source shell script or run shell functions which set the environment prior to running the make command. 

It is not possible to use the "Program" builder to execute the script beforehand because environment variables set in the first builder are not visible to the make command in its own process context.

As a workaround I can use as the make command: sh -c "module load gcc; make" but this does not work well with the GUI (for e.g. parallel build, stop on first error) and is not intuitive to people new to CDT.

Thus I suggest that an option is added that one can add a list of commands, which are executed before make but within the same process of make. This function could be use to run any commands but it is meant to run environment variable setting commands because others could use the "Program" builder.  

Since it is meant for environment variables I suggest to add it to the environment page. I suggest to add an additional list below the variable list for these commands and an additional "Add command" button to add these commands to the list. 

We are happy to provide a patch which adds this functionality. But we would like to first get input on how to improve the suggest new functionality (e.g. the UI to add these commands).
Comment 1 Andrew Gvozdev CLA 2011-02-18 22:12:31 EST
(In reply to comment #0)
> We are happy to provide a patch which adds this functionality. But we would like
> to first get input on how to improve the suggest new functionality (e.g. the UI
> to add these commands).
There is "Build Steps" tab on "Settings" page (for managed projects). I think this UI suits the idea with some adjustments like multiple commands.
Comment 2 Roland Schulz CLA 2011-02-19 00:12:07 EST
It is close to the idea. ( I never use managed project and thus didn't know that option). But it would have to be available also for non-managed projects. 

Thus I suggest:
- Add support for several Pre and Post Commands
- Add support for this feature for non-managed projects

For non-managed projects it should use a shell to execute the list of commands (pre+make+post). I'm not sure how to do this best under Windows (in case this feature is supposed to be supported their to).
Comment 3 Chris Recoskie CLA 2011-12-06 14:50:08 EST
This would require some rework compared to how things work now.  Currently, the various commands that the build launches are individually launched in their own shell instances.  In order to have the environment variables persist between the commands, you'd need to execute the commands in the same shell.
Comment 4 Roland Schulz CLA 2011-12-06 16:29:06 EST
(In reply to comment #3)
> This would require some rework compared to how things work now.  Currently, the
> various commands that the build launches are individually launched in their own
> shell instances.  In order to have the environment variables persist between
> the commands, you'd need to execute the commands in the same shell.

Maybe it would be easier to import (/source) environment variables from a script. I imagine this could work the following way:
- The user provides a script/command which sets the variables
- CDT queries the remote environment (e.g. by running 'sh -c export')
- CDT executes the script followed by re-querying the environment
- CDT then compares the two environments and adds the added/modified variables to the list of environment variables. 

This would allow the user to easily import and the environment variables from the script into CDT and would have the same effect as running the script before every command.

The only difference is when the script changes. If the variables are imported than any changes in the script has no effect on the variables in CDT.

I think this has both advantages and disadvantages. It depends on what the user expects. If it is a system script he might always want to use the latest version or he might want to use the version originally imported.
Comment 5 Jeffrey Overbey CLA 2011-12-06 16:46:25 EST
(In reply to comment #3)
> Currently, the various commands that the build launches
> are individually launched in their own shell instances.

Hi Chris, what are "the various commands" exactly?  Obviously make, but what else?  Scanner discovery or something?
Comment 6 Leo L CLA 2014-02-06 10:32:48 EST
I would suggest that this feature be independent of the build process. Maybe it even belongs in Eclipse, not CDT. The use case I currently can't address is to automate launching. I currently use make as the command to "Run" because I need some dynamic environment variables. While that works, it is not particularly intuitive. Roland's suggestion is a brilliant, simple, user-configurable way to greatly enhance Eclipse's functionality without adding another scripting layer. The user could use whatever shell they are most comfortable with to change the environment before any build or run.