This post is not about variables in my application code (which I debug). It is about using Variables in Eclipse for building projects. Eclipse variables allow me to make my projects ‘position independent’ whenever I cannot use a path relative to my projects or workspace.
Eclipse Variables
Which variables are used where in Eclipse might be sometimes not very clear. Depending in which context variables are used, not everything might be available. This link for example gives a list of variables which can be used to invoke an external tool.
Build Variables
Eclipse comes with many built-in variables, especially for the build system. If I want to see what variables are already defined, I can show them in the project properties, under C/C++ Build > Build Variables with enabled option ‘Show system variables’:
System Build Variables
With the ‘Add…’ button I can define and add my own variables, available for that project:
Define a new build variable
If above operation is done on a project, then the setting is for the project only. If I want to add a variable for the workspace, I can do this using the menu Window > Preferences:
Workspace Build Variables
Global System Variables
Eclipse automatically includes the system (e.g. Windows) environment variables. Many dialogs have the ‘Variables…’ button where I can use my variables, including the variables defined on system level:
System Variables
System variables: one way or the other
So if I want to have a variable for every workspace, one way is to define it at the system level. However, this is not a good way as this clutter the variables for every application.
Batch File
A solution to this to create my custom batch file where I define my variables, and at the end of this batch file I launch Eclipse. That way the extra variables are only for this Eclipse session.
cwide-env File
Another very nice way CodeWarrior Eclipse offers is using the cwide-env file located in the eclipse sub-folder of the installation:
cwide-env File
I can define variables here, or extend existing ones:
- -add: add string to the variable at the end
- -prepend: add string to the variable at the beginning
That way I can easily manipulate existing system variables or create new ones which then are used by Eclipse.
Summary
Variables in Eclipse help me to define paths to source files and folders outside of a project or workspace. With variables I avoid using absolute paths which would make porting projects from one machine to another difficult. I can define variables for projects, for the workspace or use system variables. With CodeWarrior I have a cwide-env file which is used to extend the system variables.
Happy Variabling 🙂
Pingback: Link to Files and Folders in Eclipse | MCU on Eclipse
Is the current Build Configuration (Debug, Release, etc.) named in any Build Variable?
There doesn’t seem to be anything relevant in the full Build Variables list…
LikeLike
Yes, there is ${ConfigName} for this which results to something like ‘Release’ or ‘Debug’ (your build configuration name).
LikeLike
Q: Can I use the value of a build variable as a string in my project code?
I’ve started including my current git hash in my builds, as a const string.
Usually, I use a script to generate a header file, something like this:
HASH_VALUE=$(git rev-parse HEAD)
echo \#define HASH \”$HASH_VALUE\” > hashHeader.h
So, I end up with a double-quoted string containing the hash value as a symbol, eg.:
#define HASH “91922c56cf806ad44f2f82178cb4963928794cdb”
Then I can use it to initialize a string, in some .c file, like:
#include “hashHeader.h”
const char current_hash[] = HASH;
So, new Q: Can Eclipse’s Build Variables and Symbols accomplish the same thing?
I experimented with this a little. Eclipse doesn’t properly handle double-quoted symbol values. The resulting compiler command line defines are malformed, and cause all sorts of errors. Like, if you set the symbol SymbolName to “quoted string”, you’ll get:
-D”SymbolName=”quoted string”
That define contains unmatched quotes. That’s clearly nonsense.
It also means that I can’t bring in a Build Variable, like, ${workspace_loc}, as a string.
It should be easy, by just defining a new symbol with the value of a Build Variable.
Try it! Define a symbol, WORKSPACE_LOC as \”${workspace_loc}\” .
The resulting string isn’t properly quoted, and it results in a bogus -D parameter passed to the compiler.
Here’s the generated command line and the error from Eclipse when I hit Build:
arm-none-eabi-gcc … -D”WORKSPACE_LOC=\”C:\nxp\cec_ucosiii\”
syntax error: unterminated quoted string
This is in KDS 3. It reports Eclipse Platform version 4.4.2.v20150204-1700.
Is this a known issue? Is there a workaround within Eclipse?
Wait. There IS a workaround. I’m a little embarrassed to even post this.
I changed my symbol name to this: WORKSPACE_LOC” .
Note the SINGLE, TRAILING DOUBLE QUOTE. Ugh, that’s ugly. But it worked:
arm-none-eabi-gcc … -D”WORKSPACE_LOC”=\”C:\nxp\cec_ucosiii\”
Finished building
LikeLike
The syntax of the -D compiler option is to define a C/C++ symbol with some content, same as
#define MY_DEFINE “this is my define content”
which would be
You cannot use a string for the #define, so you should not use double quotes for your workspace location.
Instead, use
Which translates e.g. to
I hope this helps,
Erich
LikeLike
I agree, those -D definitions would work fine on the command line.
But they don’t work with Eclipse’s “Paths and Symbols” -> Symbols.
(Is this peculiar to me? To KDS? Or to my installation?)
Seems there was a bug filed against this issue, many years ago.
Never closed:
https://www.eclipse.org/forums/index.php/t/71837/
https://bugs.eclipse.org/bugs/show_bug.cgi?id=309158
And the (super-hacky) workaround I described produces incorrect results. I used an unmatched trailing double-quote in my variable name:
WORKSPACE_LOC”
and set it equal to the Build Variable, in escaped quotes:
\”${workspace_loc}\”
That compiled OK, so I declared victory. But I just tested it. And:
Printf displays WORKSPACE_LOC as: C:nxpcec_ucosiii
The backslashes on the command line need to be escaped 😛
That path should have been: C:\nxp\cec_ucosiii
But it works fine with simpler strings, like defining:
Symbol CONFIG_NAME” as \”${ConfigName}\”
And PRINTF(“%s”,CONFIG_NAME) prints: Binary_Release
The last post (2014) on the bugzilla thread was:
https://bugs.eclipse.org/bugs/show_bug.cgi?id=309158#c5
…surround the symbol definition with single quote (‘). The result for symbol definition dialogue is :
‘”texvalue”‘
on the compiler invocation it’s translate to :
-DTEXTVAR=”textvalue”
Try to believe it.
That trick might have worked for the poster, but didn’t work for me at all.
Eclipse tried to surround the definition with more double quotes, and simply didn’t produce a valid string.
So, this looks to me like a genuine bug.
And it seems to stand little chance of being fixed, since no patch has been accepted since the original bug was filed in 2010.
I guess it just doesn’t affect very many users.
LikeLike
Dealing with path separators and file/paths with spaces has been a challenge for a long time. I doubt it will be solved to 100% in the near future.
What you could consider is a pre-build step/script (https://mcuoneclipse.com/2014/09/23/executing-multiple-commands-as-post-build-steps-in-eclipse/): say writing a script (Perl, Python, etc) which reads the .cproject file and generates a header file with the defines you need? I know that takes some efforts, but probably would be a working path.
LikeLike