CODEWITHSUNDEEP
ceclipseeclipse-cdt
JonS
JonS

Reputation: 651

Using Build Variables in C code with Eclipse 4.4.2

I have a project that I created previously using Eclipse 3.5.2. In it, I was able to set a Build Variable in the project properties. In this case, let's say I set SW_VERSION to be 4403. Now this is intended to be a hex number, so in the Build Settings, I added a Symbol "VERSION=0x${SW_VERSION}" entry. Then in my code, I was able to use VERSION as a regular number, like so:

unsigned int vers = VERSION;

There was no problems, and vers got the value 0x4403.

Now I'm using Eclipse version 4.4.2 and I'm updating my project with some new features. But first I'm just trying to re-compile my old project with the new toolchain, and while I don't get any messages on the Console, I get 3 warnings in the Problems tab:

Symbol 'SW_VERSION' could not be resolved
Symbol '$' could not be resolved
Statement has no effect 'VERSION'

I haven't tried running the completed project yet, but this concerns me and I have to assume that it won't actually work like it used to. Is there some different way to do this in the newer Eclipse or is this feature just gone?

As a side note, there is a reason why I did it that way. I also have the value of SW_VERSION appended to the end of my artifact name. That part still works at least.

Upvotes: 2

Views: 2572

Answers (2)

HighCommander4
HighCommander4

Reputation: 52799

You say:

Makes the thing kind of pointless if it can't actually analyze what the code actually is. I did this and it works, but it makes the pop-up macro expansion show this fake value rather than the real thing.

But I bet in Eclipse 3.5.2, the pop-up macro expansion wouldn't even come up for VERSION.

In other words, the indexer was never resolving VERSION correctly. The only thing that changed, I believe around Eclipse 3.7, is that indexer errors started to be surfaced in the UI, which I why you would have started seeing errors like Symbol '$' could not be resolved.

Now, regarding solving your problem: is the build output parser (Project Properties -> C/C++ General -> Preprocessor Include Paths, Macros etc. -> Providers tab -> <Your Toolchain> Build Output Parser) enabled?

It should be able to pick up the correct value of VERSION for the indexer, by parsing the output of the build, including the compiler invocations (which presumably contain the expanded value of ${SW_VERSION}, otherwise compilation wouldn't work).

I don't have much experience with generated makefile projects (I write my own makefiles), but I think the build output parser should work for them too.

Upvotes: 1

Victoria_La
Victoria_La

Reputation: 91

Indexer (CDT parser) sees your VERSION macro and expands it to 0x${SW_VERSION} but does not evaluate it so it passes it to preprocessor as is unexpanded, these warning are coming from static code analysis and wont affect your binary. But since it annoying to see that you have to force indexer to see this macro properly by defining VERSION macro for indexer only

  • project properties->C/C++ General->Preprocessor ..->
  • Select GNU C (or whatever language variant you use)->
  • Select CDT User Setting Entries
  • Click Add... and add "Preprocessor macro" VERSION=1

It does not matter what number you put there since it won't be in your binaries, it is just for syntax parsing.

Upvotes: 2

Related Questions