Compiler Defines and Eclipse Editor Highlighting

Posted on October 5, 2012 by Erich Styger

In this post I have found settings for Eclipse Indexer to show the state if defines correctly. Usually I have something like this in my projects:

debug me

So I define the macro DEBUG_ME on the compiler command line. And it is cool to see that the Eclipse editor correctly grays out the code which is not enabled. But for this the Eclipse Editor view needs to know about the macro, but how does this work?

The reality is: that works out of the box for many tool chains, but not for all.

Kinetis ARM gcc

It works perfectly for the ARM gcc as in MCU10.3. And it works because the editor knows that this symbol is defined in the Path and Symbols information of the project:

Path and Symbols with DEBUG_ME

This, because this symbol is added automatically to the symbols list, because I have defined it in the compiler preprocessor settings for the Kinetis ARM gcc compiler:

Compiler Preprocessor

Without going into the details: The Eclipse Managed Make framework and option settings offers the above -D control, and if used by the build tool panels, the options are automatically added/removed from the symbols.

Freescale (non-gcc) ARM/Kinetis Compiler

That feature exists as well for the Freescale (non-gcc) ARM/Kinetis compiler under ARM Compiler > Input:

Freescale ARM Compiler Input

Freescale S08 Compiler

The same thing is found for the S08 compiler under HCS08 Compiler > Preprocessor:

HCS08 Preprocessor

Freescale ColdFire Compiler

Unfortunately (at least up to MCU10.3 beta) such a panel is not present for the Freescale ColdFire compiler. I can use the -d compiler option to pass my defines:

ColdFire define

But: this has no meaning for the Eclipse editor. The compiler knows about the symbol, but not the Editor view. And because this managed make integration into eclipse is not using the panels as shown above, the # Symbols tab is missing too, so I cannot add manually a symbol? 😦

Missing Symbols Tab

I have filed a feature request, so hopefully this could be added. Until then, the Eclipse editor view is innocent and does not know what I have defined on the compiler side.

💡 If you have found a solution for that problem, then please post a comment 🙂

PowerPC Compiler

A similar story for the PowerPC compiler. There is no separate settings for preprocessor defines, but can be added using the -d option as shown below:

Define option for a PowerPC project

The option -d DEBUG_ME=1 is equivalent to have

#define DEBUG_ME 1

in all sources. What that compiler Eclipse integration offers is to specify a prefix file: instead of passing the defines on the command line, they are put in a normal text file:

Preprocessor prefix files

Summary

The way how to specify compiler defines is different from compiler to compiler. At least there is a command line options common to all of them. But only using the Eclipse CDT special panel for defines ensures that Eclipse is aware of the symbol definition.

Happy Defining 🙂

20 thoughts on “Compiler Defines and Eclipse Editor Highlighting”

Catherine Bezy on October 8, 2012 at 13:38 said:

Hello Erich

Did get a quick look at this one.
When building for Coldfire V2 or V3, if you want to get correct conditional code display in your source code you can use a prefix file instead of using -d option to define your macro.

For instance to define a macro called DEBUG_ME, just create a file prefix.h and specify it as prefix file in the C/C++ Build > Settings > Coldfire Compiler > Input page.

The prefix file should include #define statement for the macros you want to define and also include the default prefix file.

To retrieve the name of the prefix file preprocess one of your source file. The default prefix file might be lib_ewl.prefix or lib_c99.prefix.
These files are stored in {Install}\MCU\ColdFire_Support\ewl\EWL_C\include folder.

I agree with you that adding a new edit box similar to what has been done for HCS08 or ARM is more elegant. But until this gets implemented, you can work with a prefix file.
Catherine

LikeLike

Reply ↓
- Erich Styger on October 8, 2012 at 17:15 said:
  
  Hi Catherine, yes, that prefix file simplifies passing or defining multiple defines. Still, it does not affect the editor coloring.
  
  LikeLike
  
  Reply ↓
  - Catherine Bezy on October 9, 2012 at 08:02 said:
    
    It does on my V10.3.0 installation. Did you rebuild indexing for the project?
    
    Click right on the project name in the CodeWarrior Projects view and select Index > Rebuild.
    
    LikeLike
    
    Reply ↓
    - Erich Styger on October 9, 2012 at 12:50 said:
      
      Interesting, that indeed works for me in a new MCU10.3 project, thanks for the tip!
      
      LikeLike
SutoCom on October 8, 2012 at 16:57 said:

Reblogged this on Sutoprise Avenue, A SutoCom Source.

LikeLike

Reply ↓
Michael Moore on February 4, 2014 at 21:49 said:

Were you able to resolve this issue? I am having a similar problem. I need to add include paths so that the indexer can recognize all of my symbols, but for some reason when I go to Project Properties -> C/C++ General -> paths and symbols I can not see the Includes or the Symbols tabs. The tabs seem to be visible in one version of eclipse, but not another. This seems to be a common problem. I see lots of hits when searching for a solution, but no explanation of how to resolve it. Thanks for the help.

Michael

LikeLike

Reply ↓
Plyblu on December 5, 2016 at 20:44 said:

Using the excellent GNU Arm Eclipse plugin (using Eclipse Mars), I see 4 places to put compiler preprocessor define symbols:
1) C/C++ Build -> Settings -> Cross Arm C or C++ Compiler -> Preprocessor
2) C/C++ Build -> Build Variables
3) C/C++ General -> Paths and Symbols -> Symbols
4) C/C++ General -> Preprocessor Include Paths, Macros etc.

#3 is the place that Eclipse CDT documentation “Adding Include paths and symbols in Managed Build System” says to use.

All but #1 allow for different symbols for different Build Configurations.

Not sure why there are so many places to do this in the Eclipse CDT user interface. There is little documentation on why to use one place versus another. Unless someone has better advice, I will use #3 above because it has the most authoritative documentation.

LikeLike

Reply ↓
- Erich Styger on December 6, 2016 at 09:14 said:
  
  You should use the 1) way: this is how things are passed to the compiler as defines.
  2) is something different (see https://mcuoneclipse.com/2013/12/22/eclipse-build-variables/) and is not about preprocessor defines.
  3) is derived/propagated from 1)
  4) is something probably you should not touch as these are settings of the build integration.
  Bottom line is that 1) is the way to set preprocessor symbols and defines.
  I hope this helps,
  Erich
  
  LikeLike
  
  Reply ↓
Plyblu on December 6, 2016 at 15:45 said:

In testing the behavior, 3) is propagated from 1), and also 1) is propagated from 3), so it appears 1) and 3) are equivalent, so either can be updated by the user with the same result. Thanks for explaining to me that 2) is something completely different.

LikeLike

Reply ↓
Vincent on July 6, 2017 at 18:32 said:

With Tasking Compiler for Tricore I solved this issue enabling specific indexer settings into C/C++ General – Indexer settings.

You need to tell the indexer to start again when swapping build configurations.

-> Enable specific settings
-> Store settings with project
-> Index unused headers
-> Use active build configuration
-> Reindex project on change of active build configuration

LikeLike

Reply ↓
- Erich Styger on July 6, 2017 at 19:10 said:
  
  Hi Vincent,
  I might be wrong, but I did not had to re-run the indexer if changing build configurations. What version of Eclipse are you using?
  Erich
  
  LikeLike
  
  Reply ↓
  - Vincent on July 7, 2017 at 15:31 said:
    
    Here is the version ID
    Eclipse Platform 4.5.1.M20150904-0015
    Vincent
    
    LikeLike
    
    Reply ↓
    - Erich Styger on July 7, 2017 at 15:39 said:
      
      Eclipse MARS.
      
      LikeLike
    - Vincent on July 7, 2017 at 15:46 said:
      
      I’m sorry I’m quite a newbie with Eclipse, I don’t understand what “MARS” mean.
      
      LikeLike
    - Erich Styger on July 8, 2017 at 16:21 said:
      
      Hi Vincent,
      4.9 is the version of the Eclipse MARS build, see https://en.wikipedia.org/wiki/Eclipse_(software).
      Erich
      
      LikeLike
Andrew Coad on May 19, 2022 at 10:25 said:

This blog is a little old but I’m struggling with preprocessor symbols in Eclipse Version: 2021-09 (4.21.0).
I define symbols in the Project->Properties->C/C++ Build->Settings->GNU ARM C Cross Compiler->Preprocessor panel and, in general, this works. However, every now and then, I get a symbol attached to specific files that 1) I didn’t put there, 2) it doesn’t change when I change the symbol at the project-level in the above panel, and 3) worst of all, the scanner that greys out the code not covered by the symbol works at the project level, not the file level, so what you see on-screen is not what gets compiled.
I don’t know how to get rid of symbols at the file-level. Just deleting them doesn’t work (the project-level symbol doesn’t take precedence so it is effectively removing the symbol completely). I have posted multiple questions on the Eclipse forum about this but have had no response at all. I have not found a pattern as to when a symbol becomes active at the file-level – they just seem to randomly appear.
Any insights into what is going on here would be welcome!!
Regards,
AC

LikeLiked by 1 person

Reply ↓
- Erich Styger on May 19, 2022 at 12:55 said:
  
  Hi AC,
  as for the symbols: what gets greyed out or not is based on the ‘index’, so it might help that you rebuild it (see https://mcuoneclipse.com/2012/03/20/fixing-the-eclipse-index/)?
  Is that symbol in question listed in the ‘paths and symbols’ list or not? You might open the .cproject file with a text editor to check/change it if nothing else helps to remove it.
  
  LikeLike
  
  Reply ↓
  - Andrew Coad on May 20, 2022 at 11:05 said:
    
    Hi Erich,
    Thanks for your reply. Yes, I have rebuilt the index many times with no effect. The misbehaving symbols at the file level are listed in the “Paths and Symbols” panel but with different values. Changing a symbol value in the Preprocessor pane changes the value in the “Paths and Symbols” pane but does not change the value at the file-level.
    To deal with this, when I change a symbol value, I then do a global search for that symbol and manually edit any entries in .cproject that are incorrect.
    What I do not know is how the symbols got attached at the file-level in the first place. I certainly didn’t put them there and it doesn’t happen for every symbol, just a random few. I also don’t know how to get rid of them. Deleting a symbol for a given file has the effect of un-defining the symbol even if it is still defined at the project level. Grrrr…
    Regards,
    AC
    
    LikeLiked by 1 person
    
    Reply ↓
    - Erich Styger on May 20, 2022 at 11:23 said:
      
      Did you copy that project from another one by any chance? I noticed that I was running into issues as projects in the workspace shared same ‘magic’ number IDs in the .cproject, because I had copied it. So if you use that project in question in a new workspace, does the problem show up too?
      
      LikeLike
Andrew Coad on May 20, 2022 at 16:33 said:

It is a project imported from GitHub, so, yes, it’s copied. Maybe I can try cleaning up all symbols by directly editing .cproject, push it back to GitHub and start afresh…

LikeLike

Reply ↓