Eclipse Build Variables

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

System Build Variables

With the ‘Add…’ button I can define and add my own variables, available for that project:

Define a new build variable

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

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

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

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.


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 🙂

7 thoughts on “Eclipse Build Variables

  1. Pingback: Link to Files and Folders in Eclipse | MCU on Eclipse

  2. 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…


  3. 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


    • 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
      -DMY_DEFINE=”this is my define content”
      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,


      • 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:

        And the (super-hacky) workaround I described produces incorrect results. I used an unmatched trailing double-quote in my variable name:
        and set it equal to the Build Variable, in escaped quotes:

        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:
        …surround the symbol definition with single quote (‘). The result for symbol definition dialogue is :
        on the compiler invocation it’s translate to :
        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.


What do you think?

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

This site uses Akismet to reduce spam. Learn how your comment data is processed.