#ifdef's ignored by the Arduino pre-processor, linking additional libraries.

[GoogleCodeExporter]

#undef NOTDEF
#ifdef NOTDEF
#include <Wire.h>
#endif

The I2C/TWI Wire library (in this example) still gets included even with the 
above code. In fact, any #include that begins at the start of a line causes the 
corresponding library to get loaded, even if the #includes are surrounded by /* 
and */ comment tokens on lines before and after the #include.  This makes it 
more difficult to modularize code in memory-constrained environments.

What is the expected output?
The expected behavior is that any code or compiler directive should not be 
honored if it is part of a /* */ comment or #if/#ifdef code block that does not 
evaluate to true.

This behavior was observed on Arduino 1.0 running on Mac OS X 10.6.8.
It is not specific to any particular Arduino board.

Original issue reported on code.google.com by tefer...@gmail.com on 5 May 2012 at 1:37

[GoogleCodeExporter]

Issue 987 has been merged into this issue.

Original comment by dmel...@gmail.com on 19 Jul 2012 at 2:23

[GoogleCodeExporter]

The Arduino pre-processor doesn't understand #ifdef's or other pre-processor 
directives.  It links in libraries placed within "#if 0" and other false 
checks.  It also places the automatically generated function prototypes without 
regard for these directives, which often leads to various problems.  

This is tricky to fix and to test (there are lots of different cases).  For 
now, you may want to avoid the use of #ifdefs and #if 0 in your sketch or, at 
least, for commenting out unused libraries or at the beginning of your sketch 
(using them later in the code shouldn't affect the placement of the function 
prototypes).  

Original comment by dmel...@gmail.com on 19 Jul 2012 at 2:28

• Changed title: #ifdef's ignored by the Arduino pre-processor
• Added labels: Component-IDE

[GoogleCodeExporter]

Are you saying they don't work at all ? Or just too buggy to be useful, because 
#ifdef's appear to do something in those examples I gave, just not what anyone 
would expect. 

If #ifdef is so seriously broken, and unlikely to be fixed, would it be better 
not to recognise them at all, or at the least to remove them from the official 
documentation such as: http://arduino.cc/en/Hacking/LibraryTutorial 

This latter was what confused me, I expected opinions on forums to be of a 
varied quality, but assumed the Tutorial had to be correct :-(

Original comment by mitra.ar...@gmail.com on 19 Jul 2012 at 4:16

[GoogleCodeExporter]

Also ... isn't there a standard pre-processor that C for example uses, that 
could be used in this case, I just get the feeling that this has been done 
before. 
http://en.wikipedia.org/wiki/C_preprocessor

Original comment by mitra.ar...@gmail.com on 19 Jul 2012 at 4:21

[GoogleCodeExporter]

The #ifdefs work fine in .cpp, .c, and .h files, since those aren't 
pre-processed (that includes files in libraries, like in the tutorial you 
reference).  They work in your sketch files (.ino files) too but can interact 
with the Arduino pre-processor in ways that lead to the errors people have 
seen.  

Original comment by dmel...@gmail.com on 20 Jul 2012 at 3:00

[GoogleCodeExporter]

Thanks - I didn't realize there was a seperate Arduino pre-processor. 

Original comment by mitra.ar...@gmail.com on 21 Jul 2012 at 12:26

[GoogleCodeExporter]

If this functionality is broken, shouldn't the documentation 
http://arduino.cc/en/Hacking/LibraryTutorial 
be edited so that it points this out - or at least warn people to put a ; on a 
line by itself before every #ifdef as this seems to at least work around the 
bugs. 

Original comment by mitra.ar...@gmail.com on 28 Jul 2012 at 9:10

[GoogleCodeExporter]

In the library, the #ifdef functionality works exactly as you'd expect because 
the Arduino pre-processor doesn't touch its files (which are all .c / .cpp / .h 
and not .ino or .pde).

Original comment by dmel...@gmail.com on 31 Jul 2012 at 12:35

[GoogleCodeExporter]

I'd still suggest that some documentation would be worthwhile, if you search 
for "ifdef arduino" the library tutorial is what comes up, there doesn't seem 
to be any documentation I could find on how to use pre-processor directives in 
the main arduino file, and there are a lot of people in various forums having 
problems with figuring out what should be included and what shouldn't, the 
combination of figuring out the #includes, while not realizing that #ifdef's 
aren't working properly seems to be frustrating people. 

Original comment by mitra.ar...@gmail.com on 4 Aug 2012 at 4:20

[GoogleCodeExporter]

This just nailed me, and I'm miffed. Is it too hard to parse a line starting 
with '#' to give a clear error msg? But thanks for the info that code in 
libraries gets preprocessed. I can use that as a workaround.

Original comment by peteso...@gmail.com on 9 Aug 2012 at 1:31

[GoogleCodeExporter]

This is a link issue rather than a compile issue, right?  The C code doesn't 
actually include the .h file inside the ifdef (they're properly processed by 
the compiler), but the arduino code that figures out which libraries should be 
added to the linker line isn't smart enough to leave them out of the link 
phase.  ??  So it's a relatively minor code bloating issue (code other than ISR 
code should get omitted by -gc-sections?)

Original comment by wes...@gmail.com on 9 Aug 2012 at 2:10

[GoogleCodeExporter]

No - its worse than that, since as dmel says, the #ifdef's are NOT processed 
correctly, things get included that shouldn't be and it breaks code in 
unpredictable ways as seen by a lot of strange results in questions asked 
around the forums. 

Original comment by mitra.ar...@gmail.com on 11 Aug 2012 at 11:04

[GoogleCodeExporter]

Is this a problem with #ifdef or a problem with commenting out? Or both? I'm 
finding my libraries get included even when they are commented out, which makes 
life somewhat tricky.

(I'm using an Arduino Nano v3.0 and the 1.0.1 IDE.)

Original comment by jezwes...@gmail.com on 14 Aug 2012 at 11:20

[GoogleCodeExporter]

Are you sure that there is an error processing the sketch itself?  I 
instrumented OneWire.h with a "#warning testing issue 906" line, imported the 
onewire library to blink via the "import library" command, and then used 
various forms of removing the #include from blink.h (#if 0, /* */, //)

I never get the warning from the compilation of the pre-processed blink.cpp 
file, though the IDE does try to compile the onewire.cpp library, and that 
generates the warning.

Could someone who has a case where the preprocessor is doing the wrong thing 
attach a full log of the compilation, AND the preprocessed .cpp file (which 
should be available in the tmp directory after the "verify" step)?

Original comment by wes...@gmail.com on 15 Aug 2012 at 5:51

[GoogleCodeExporter]

The actual compilation of the sketch .ino files happens correctly, with the 
gcc/g++ pre-processor doing what you'd expect. The problem is that the Arduino 
IDE's pre-processor doesn't know about C pre-processor directives like #if or 
#ifdef and so it will link in libraries that you #include, even if that 
#include is within an #if 0 (or similar) block. This can cause errors like 
duplicate symbol definitions. 

Original comment by dmel...@gmail.com on 15 Aug 2012 at 1:39

• Changed title: #ifdef's ignored by the Arduino pre-processor, linking additional libraries.

[GoogleCodeExporter]

This could help fixing the issue:
http://www.a-control.de/arduino-fehler/?lang=en

Original comment by adri.du...@gmail.com on 19 May 2013 at 3:26

[GoogleCodeExporter]

Verified with Arduino 1.5.2 on Windows 7.

The case was a library which defined ISR(TIMER1_COMPA_vect), and gave a 
compilation error on reference to OCR1B. This is undefined on the Due, and 
although I used ifdef to avoid the #include, I still got the compile error.  So 
now I need to comment out/in the include when switching boards. 

This unexpected and strange behaviour makes Arduino a flaky environment to 
develop in.

The workaround suggested above by our German friend is ingenious, but just 
makes the code even more flaky.

Original comment by pwbec...@hotmail.com on 4 Sep 2013 at 4:17

[GoogleCodeExporter]

Yes it's unfortunate that the poor compiler lets down what are often quality 
products. Ive done some bug fixing on the open-source libraries but wouldn't 
know where to start on the compiler.  

If critical bugs like this are still preset after well over a year it's clear 
the developers aren't going to fix it 

Does anyone know if someone has forked the code to create a reasonably high 
quality product that can still use the libraries. 

- Mitra 

--- Mitra Ardron 
+1(519)423-1767 San Francisco 
+1(510)984-2639 forwards to me 
Typos courtesy of my iPhone

Original comment by mitra.ar...@gmail.com on 4 Sep 2013 at 5:57

[GoogleCodeExporter]

Please checkout this thread [1] on devs mailing list and try one of the linked 
IDEs. It should fix the problems reported in this issue
[1] 
https://groups.google.com/a/arduino.cc/d/msg/developers/4X2T3rCxXWM/WbQ2_dGzuhsJ

Original comment by federico...@gmail.com on 27 Jan 2015 at 2:17

[GoogleCodeExporter]

Original comment by federico...@gmail.com on 26 May 2015 at 3:27

• Changed state: Fixed