Go Down

Topic: IDE - Ignoring '#ifndef' directive ?? (Read 123 times) previous topic - next topic

BenKenobi

Using IDE 1.6.5 R2 I'm getting frustrated by ': multiple definition of ' type errors for a library .h file that has a conditional header i.e

#ifndef XYZ_H
#define XYZ_H

...
...

#endif

so I include <xyz.h> in my app, I also include "xyz.h" in my library class xyz.cpp file - and yet at compile time the IDE bitches about duplicate definition of items - which there shouldn't be if it was obeying the #ifndef directive.

Am I missing something here - I thought the purpose of #ifndef was to prevent multiple inclusion of code or definitions.

Once Only Headers - GCC

PaulS

Quote
Am I missing something here
Yes, indeedy - your code!

BenKenobi

I have it up elsewhere - should have linked - I'm currently messing around with definition locations but it is attached.

I've tried a few ways to handle the 'globals' as I am trying to avoid wasting space - i.e. a local .h in my application with 'extern' definitions but when I tried this the code didn't work - compiled but didn't work.

I think the library needs more autonomy though with less 'shared' - but again I'm trying to save space as a lot more will be going into this.  I'm just trying to 'relocate' variable definitions at the moment.

This is a combination of trying to understand how the code author was thinking, learning the math side of things and also building coding skills.

Vaclav

This is well known problem with IDE mutilating preproccessor directives in x.ino file.
It really acts differently in different releases.
In 1.6.6 older nightly build I am using I cannot use system (<system file>) includes in ANY "local" header files.
The system includes have to be in the main x.ino , but the local ("header file" ) are included properly no matter where they are.
 
Your mileage will vary.

BenKenobi

I have moved stuff around and modified some of the function calls and now it compiles - but I still think there's a defect here based on everything I've read elsewhere.

The compiler should not be including anything inside #ifndef if the condition is not true - i.e. the block is already defined - regardless of what is there it should be created only once.

PaulS

Where is the sketch that uses the header file?

Where are the error messages?

BenKenobi

That sketch no longer exists, things have moved on.

Basically any ino that loads the library as posted i.e. MPU9150.h / MPU9150.cpp will show the error on my set up.

PaulS

Quote
That sketch no longer exists, things have moved on.
You've changed the code. You don't like what you had to do, but you did not explain what you did, or why you don't like it. And, yet you don't want to post all of the code. Moving on seems like a really good idea.

BenKenobi

Quote
"Moving on seems like a really good idea"
I don't get the attitude, not the first time I've encountered it here, I explained what I was doing and what I did - moving stuff around and changing functions


The original ino doesn't matter, even a basic ino containing only a reference to the library will show the compilers disregard of the directive.



oqibidipo

Just what I suspected from the start even before seeing the code.
Variable definitions in a header file.

MPU9150.h:

Code: [Select]

uint8_t Ascale = AFS_2G;     // AFS_2G, AFS_4G, AFS_8G, AFS_16G
uint8_t Gscale = GFS_250DPS; // GFS_250DPS, GFS_500DPS, GFS_1000DPS, GFS_2000DPS
float aRes, gRes, mRes;      // scale resolutions per LSB for the sensors

(and a lot more)


Of course you are going to get complaints about duplicate symbols, if you include this in two or more source files that are linked together.

BenKenobi

Not ideal granted but why would they even be 'processed' if they are within an #ifndef #endif directive and have been defined once.


oqibidipo

The source files are compiled separately. The header file has not been "already included" during each compilation.

BenKenobi

Ah - so it is only #ifndef for the current file not for the project as a whole ... makes sense I guess.

Go Up