Bugzilla – Full Text Bug Listing
| Summary: | Managed build assumes compiler is in PATH environment variable | ||
|---|---|---|---|
| Product: | [Tools] CDT | Reporter: | Oyvind Harboe <oyvind.harboe> |
| Component: | cdt-build-managed | Assignee: | Project Inbox <cdt-build-managed-inbox> |
| Status: | RESOLVED FIXED | QA Contact: | Chris Recoskie <recoskie> |
| Severity: | enhancement | ||
| Priority: | P3 | CC: | EclipseBug.Tracker, leh, Rekha.Deshmukh |
| Version: | 3.0 | ||
| Target Milestone: | --- | ||
| Hardware: | All | ||
| OS: | All | ||
| Whiteboard: | |||
|
Description
Oyvind Harboe
I'd like to see environment variables as part of the build settings. That'll let you build for multiple environments in the same workspace without mucking with your global environment variables. Something similar to the launcher would be great. >I'd like to see environment variables as part of the build settings. That'll let
>you build for multiple environments in the same workspace without mucking with
>your global environment variables. Something similar to the launcher would be
>great.
Are build settings part of the project?
I.e. would they be committed to CVS and shared between developers?
Øyvind
Yes. They could take advantage of the path variable feature we are planning on adding for 3.0 to make them work in team environments to deal with different install locations. Øyvind's comments about Cygwin's bin being in the PATH environment variable and causing interoperability problems rings true for not just managed make but for all Cygwin commands invoked by CDT, including standard make projects. Fortunately, there is a possible convenient solution to this. All CDT invocations of command line tools of any significance goes through the ProcessFactory and Spawner classes. One could patch the ProcesFactory.addPathsToEnv() method to add paths from a defined extension point. The extension point could be defined for the configuration to apply to all CDT. A preferences page for CDT could be adding to allow the user to add/remove/edit paths. To make the path in the extension point portable and not hard-coded, one could make an interface for the extension point that dynamically provides the full path values. I would like to see this happen as part of expanded support for the MBS macros that were added in 3.0. What I would like to do is create a workspace or project macro with my build command in it (incl full path), and then my command invocation uses the macro. This way the project can remain portable between different folders, computers, etc. Env var support would be nice for some people too, but in my case we actually have a rule that our product can't use environment variables, so I would definitely like to see the macro solution implmented as well. MBS 3.0 does have new functionality that can be used here. A project or tool- chain can provide an "environment supplier". When it is called, it can define new environment variables or append/prepend/replace existing variables. The scenario that led to its creation is for a tool integration to be abe to set up its own environment for the build. This is particluarly important when you have projects that have configurations using different tool-chains or multiple versions of the same tool-chain. I agree with comment #4 that solving this issue in MBS alone is not enough. This is an example of why I think we need CDT-wide tool-chain definitions. This would provide all of the information about a tool-chain in one extension point, rather than inventing a new extension point every time there is a piece of information that multile parts of CDT need. You can do this with macros currently. However, it's a bit of a pain because then every toolchain vendor has to create a UI to manage their own preferences so their users can specify the macro values. See the XL C/C++ toolchain. Things are further complicated because the user might use the same toolchain on several different machines and platforms, in which case the path will be different for potentially each project and each build configuration in it. Heck, they may even want to specify different compilers to use from different paths on the individual file level (weird, but possible). We need something better here. Not sure this will be worked on any time soon though, so contributions would be welcomed. You can do this with macros currently. However, it's a bit of a pain because then every toolchain vendor has to create a UI to manage their own preferences so their users can specify the macro values. See the XL C/C++ toolchain. Things are further complicated because the user might use the same toolchain on several different machines and platforms, in which case the path will be different for potentially each project and each build configuration in it. Heck, they may even want to specify different compilers to use from different paths on the individual file level (weird, but possible). We need something better here. Not sure this will be worked on any time soon though, so contributions would be welcomed. With CDT 6 I can provide compiler path from a build configuration. I do not add Cygwin or MinGW directory to the PATH but instead declare it as an environment variable, e.g., CYGWIN_PATH. Then I add to the appropriate CDT project > Properties > C/C++ Build > Environment dialogue environment variable PATH with value: ;${CYGWIN_PATH}. With this technique I can have separate build configurations for Cygwin and MinGW and invoke the correct GCC variant per build configuration. As the environment variables can be set separately in each computer, the paths need not be the same in every computer.
(In reply to comment #9) This technique was institutionalized in CDT 8.2 with introducing variables $CYGWIN_HOME and $MINGW_HOME by corresponding environment supplier. |