Compilation error: conditional #include inside #if

[e-moe]

Hi guys, I'm trying to implement one class for two different MCU types using conditional #include.
Is there any way to avoid error and specific files compilation (e.g. compile only a.cpp or b.cpp but not both of them)?

Arduino 1.6.7. Mac OS X El Capitan.

sketch/b.cpp.o: In function `I::test()':
sketch/b.cpp:3: multiple definition of `I::test()'
sketch/a.cpp.o:sketch/a.cpp:3: first defined here
collect2: error: ld returned 1 exit status
exit status 1
Error compiling.

sketch:

#if defined(__AVR_ATtiny85__)
  #include "a.h"
#else
  #include "b.h"
#endif

void setup() {
  I i = I();
  i.test();
}

void loop() {
}

a.h:

class I
{
  public:
  void test();
};

a.cpp

#include "a.h"

void I::test() {
  return; // specific code for MCU A
}

b.h:

class I
{
  public:
  void test();
};

b.cpp

#include "b.h"

void I::test() {
  return; // specific code for MCU B
}

[matthijskooijman]

Could you try the hourly build (from the downloads section on arduino.cc)? I believe that this issue might have been fixed in git recently.

[e-moe]

just checked with hourly build (2 February 2016 10:15:23 GMT) - same results:

sketch/b.cpp.o: In function `I::test()':
sketch/b.cpp:3: multiple definition of `I::test()'
sketch/a.cpp.o:sketch/a.cpp:3: first defined here
collect2: error: ld returned 1 exit status
exit status 1
Error compiling.

[matthijskooijman]

Ah, now I looked more closely at your example and indeed, this is not expected to work. The problem is that both .cpp files are compiled, regardless of whether the corresponding .h file is included. Arduino or the compiler has no way to match .h files with .cpp files, so all .cpp files in a sketch are always compiled. There is currently no way to specify what files to (not) compile. I can see ways around this:

• Put the contents of a.cpp and b.cpp in a big #ifdef block. This block should depend on some macro, but since each .cpp file is compiled on its own, the .ino file does not influence them at all. Adding a custom -D option to the compiler to predefine a macro is alsno not supported, so both .cpp files should #include some .h file which you use to decide between the two.
• Put a.cpp and b.cpp (and the corresponding .h files) each in a separate library. The Arduino IDE does support detecting library dependencies and only includes only the library that you include in the build (and, with the latest hourly builds, this also works properly for #include inside #if).

Since this isn't so much a bug in the IDE, as well as a mismatch in your expectations (and because it won't be easy to change the IDE to meet your expectations in a reliable way), I'll go ahead and close this issue. Feel free to leave more comments if you have questions, though, or if you think there is something the IDE should change.

[lmihalkovic]

It might not be far-fetched or difficult to add support for arch specific code in the IDE in a manner similar to what was done in the boards packaging: the IDE could with minimum effort support arch specific folders insde the a sketch's root folder and ensure that the contents only gets compiled when the matching hardware is targetted. Possibly something Arduino Create will support?!

[mikaelpatel]

@e-moe
Why is there not a processor check in the cpp files? In any case I would structure this as 1) a single header file with processor dependent sections if needed (private or at least protected) to maintain the same interface, 2) single source file with processor dependent sections.

[cmaglie]

Possibly something Arduino Create will support?!

The build process is (and will remain) the same for the Java IDE and for Create.

It might not be far-fetched or difficult to add support for arch specific code in the IDE in a manner similar to what was done in the boards packaging

We tried to add support for the arch folder in the past exactly for that, while transitioning from IDE 1.0 to 1.5, but this change has been received very badly by the community, The opposition has been so strong that we were forced to step back and remove it.

[e-moe]

@mikaelpatel , @matthijskooijman I tried to show minimal example of code to demonstrate errors. Actually I'm trying to fix build errors in https://github.com/digistump/DigistumpArduino/blob/master/digistump-avr/libraries/DigisparkLCD/LiquidCrystal_I2C.cpp:

#if defined(__AVR_ATtiny85__) || (__AVR_ATtiny2313__) || (__AVR_ATtiny167__)
#include "TinyWireM.h"      // include this if ATtiny85 or ATtiny2313
#else 
#include <Wire.h>           // original lib include
#endif

...

#if defined (__AVR_ATtiny85__) || (__AVR_ATtiny2313__) || (__AVR_ATtiny167__)
    TinyWireM.begin();             // initialize I2C lib
#else   // original call
    Wire.begin();
#endif

...

both of these libraries (Wire and TinyWireM) trying to declare same things twice (e.g. USI_TWI) :(

[lmihalkovic]

@cmaglie thank you for sharing that part of the history of the platform. If I may ask, I found some past entries referencing the possibility of adding support for Makefile based builds in the IDE. From what I could gather, the discussions seemed centered around libraries. Has there been any similar discussions regarding support Makefile for sketches?! As I shared previously, I found that once the console stream machinery was straightened up, it was straightforward to address the 'floating' compiler messages - they follow the active editor - and even simpler to support Makefiles - basically remove most of the code from Compiler.java (I decided to expose a preference, but it is not required). In light of this apparent ease, I was wondering if there was not another deeper reason for not support Makefile.

[lmihalkovic]

@e-moe If I may share: when dealing with multi-environment code, I tend to favor a solution where inside the .h (public api) switching is done using the publicly available #define, but then turn them into something specific to the library for the conditionals inside the .cpp. This stems from the desire to try to minimize the work of adapting the code to changes in the environment (say when you switch compilers for e.g.) by avoiding having the copy the same, IMHO, longish #if defined (__AVR_ATtiny85__) || (__AVR_ATtiny2313__) || (__AVR_ATtiny167__)
Additionally when I do a search/grep, I can target directly the library's internal #defines, knowing that the results will only point to the library's code. There is really no rational other than to try to save myself work in the future.

[e-moe]

@lmihalkovic , yes. but I can't change any of these libraries (Wire or TinyWireM). They are already in use in many different projects and sketches. And because both of them declaring the same thing (e.g USI_TWI) I should make changes only in client libraries (in my case LiquidCrystal_I2C) where this variable is used. In this case I ought to import conditionally one of the dependent libs.

[matthijskooijman]

@e-moe, if I understand correctly, the original problem you had with the Wire and TinyWireM libraries selects between two libraries, while your reduced example selects between files in your sketch, making them significantly different. Did you try your original problem with the hourly build?

IIUC the code you pasted is from the .cpp file in the library you linked. However, what does the .ino sketch look like? If you're using the example from that library, you might be including TinyWireM.h from the .ino file unconditionally? If not, can you perhaps provide the full sketch and the full errors?

[e-moe]

@matthijskooijman, yep, I tried hourly build on my original problem - same results. Code samples are slightly different but they shares the same idea. Compare my reduced example:

#if defined(__AVR_ATtiny85__)
  #include "a.h"
#else
  #include "b.h"
#endif

with my original issue:

#if defined(__AVR_ATtiny85__) || (__AVR_ATtiny2313__) || (__AVR_ATtiny167__)
#include "TinyWireM.h"      // include this if ATtiny85 or ATtiny2313
#else 
#include <Wire.h>           // original lib include
#endif

[matthijskooijman]

@e-moe, yeah but the primary difference between your example and the real case is that a.cpp and b.cpp are in the sketch? Or did you create two test libraries for them?

Did you see if your .ino file perhaps unconditionally includes either library?

[e-moe]

@matthijskooijman, you right - my files was in sketch. they are not separate libs. But I also tried to compile my original issue with Wire and TinyWireM libraries with the same error message.