On my host machine I have many different development environment installed. From different make, cmake and python versions up to different versions of GNU tool chains. Adding them to the PATH environment variable on Windows is really a bad thing: instead I want to keep my PATH as clean as possible. If I need to set up a different environment with different tools, then I prefer to have a ‘local’ environment.
If you have to maintain different projects and tool chains over time, then things can get complex. What I have found out that for example with Eclipse it is fairly easy to have a local environment, both on a workspace and project level.
Global and Workspace Settings
CDT provides a powerful way to provide global (workspace) related path settings. For example I can specify both the global or workspace ARM tool chain here:
In a similar way I can set environment variables:
To check or update any other variables usable for the build, check out this setting page:
Project CWD and PWD
In the project environment, there are the CWD and PWD variables:
The two variables are pointing to the Build Directory:
This sets the ‘current directory of the processes created’: so it means that for the above case the ‘Debug’ directory is the ‘current wording directory’ (CWD), for example for the compiler.
With this in mind, it is really a bad thing what is shown below with using an absolute path like below:
With this in mind, it is much better to use relative paths: they are not only shorter, they are more portable too:
Project PATH
Another very useful variable is the PATH one:
It is the same PATH variable you know from the base (Windows) operating system. So instead polluting your global host OS PATH with some entries, I can add my per-project PATH settings. For example if I want the project to use the tools for the Raspberry Pi, I can easily add that in front of the path:
The same way I can decide which cmake, Python or other tool I want to use, as usually I have multiple versions installed on my system.
Summary
There are multiple and different levels how to affect the environment or build variables.With Eclipse it is easy to set variables or settings on an IDE, workspace or project level. That way I can have a clean setup and separation between environments. Or I can just use that one special tool for my special project, without changing any global environment.
Happy setting 🙂
Links
- Eclipse Embedded CDT project: https://projects.eclipse.org/projects/iot.embed-cdt
- Eclipse Embedded CDT: https://eclipse-embed-cdt.github.io/
MCU on Eclipse 
To ensure project portability, it is preferable to define the installation location of local tools as CDT Build Variables at workspace preference level (specific to the individual user and their tools installation). For example:
Variable: MY_TOOLS_LOC
Value: C:\mytools
Projects that need these tools can then prepend the location of these tools to the PATH environment variable for each build configuration of the project as follows:
Variable: PATH
Value: ${MY_TOOLS_LOC}/bin; ……..
The project can then be shared between multiple users without modification. Each user provides their own definition of MY_TOOLS_LOC.
LikeLike
Hi John,
yes, that’s a good approach, thanks for sharing! I use the same for referencing different depending project locations, using CDT Build variables to point to the source/library location: that way each user can have its own location of the library, plus it allows quick and easy switching between versions.
LikeLike
Hi Erich – Liviu Ionescu’s xPack approach might also be of interest as it facilitates the use of specific tool versions on a per-project basis whatever build approach is used (command line Makefile, Eclipse GUI, VSCode GUI etc.).
https://xpack.github.io/
LikeLike
Hi Tommy,
yes, I’m using that approach too. And his CDT plugins are setting the bar too, as they easily allow custom tool chains for each project.
LikeLike