2

As I understand, Arduino IDE considers two paths for the libraries:

first,

"C:\Program Files\Arduino\libraries"

and second, the "libraries" folder next to the schetchbook.

I have a configuration.h file, that I include in the main file, Test.ino, like this:

#include <configuration.h>

and in the configuration.h file I try to include SPI.h like this:

#include <SPI.h>

But I get the following error:

fatal error: SPI.h: No such file or directory

It seems that I am obliged to include SPI.h only from the ino file. But why? And how can I do what I want here? do I have to change IDE?

P.S: the software is large and I am improving maintainability.

3

It seems that I am obliged to include SPI.h only from the ino file. But why? And how can I do what I want here? do I have to change IDE?

The background is how the Arduino IDE pre-processor works together with the GCC AVR compiler and build tools.

The compiler needs to know the include path to the libraries. This is created by the pre-processor by scanning the ino file and searching the known libraries. A compiler command line is built with the include paths to the located libraries.

If you move the library includes to a configuration file the IDE pre-processor will not be able to locate the libraries and create the include paths. The pre-processor does not recursively scan library files.

Cheers!

5

See my answer How the IDE organizes things. There is no easy way to avoid having to put an include in the main .ino file, unless you write your own build process (or perhaps use another toolchain).

I think you could put SPI.h (and other things, like Wire.h) in the main .ino file, even if they aren't used due to your configuration parameters. The linker would strip them out because the modules were not referenced.

2

The IDE has to be explicitly told each and every library that you use. It also has to be told each and every library that every library that you use uses. And so on.

The Arduino IDE only looks in the INO files. As a result: if the library is not included in the main INO file then the IDE doesn't know that you intend to use it, and so it doesn't look for it.
Only when it's in the INO file will the IDE actually look for where that library is located and append the right flags (-I...path...) to the compilation commands to be able to get at the files for it.

Further, it is only then that it actually knows that it should compile the source code for a library. Without that knowledge, even if you explicitly point to the header file with a relative path, the IDE won't know that it should compile and link the source code.

There is no way around it, it's just the way the IDE works. The only option is to change to a different IDE that has more intelligence and can recursively deep-scan the libraries to maintain a list of prerequisites (such as my popular UECIDE IDE).

  • I'm not fully agreeing here. It is a decision of the arduino core team to only scan the ino files for libraries.There have been several issues raised to fix this. I do agree that the PO should consider another IDE. I however would advice to use arduino eclipse plugin called sloeber that can be found at sloeber.io. – jantje Jul 1 '16 at 10:49
  • @jantje Only because you wrote it. At least I have the good grace to mention that UECIDE is mine. If you advise someone to use something you have created you should mention that it is your product. – Majenko Jul 1 '16 at 10:53
  • Sorry I forgot. As it was you I assumed that you knew (which you do) and I forgot to mention (for the other readers) that I do develop the arduino eclipse plugin named sloeber. I think people should use the ide of their choice and choice is a good thing. So I didn't mean I do not fully agree with the IDE you propose. I probably should have done a edit :-( – jantje Jul 1 '16 at 13:01

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.