Add top-level library path to include search path when compiling libraries.

[WestfW]

Currently, the list of Include-file paths ("-I" compiler option) is computed based on the sketch files (#include strings), and the libraries themselves. For instance, to compile a ds1307 example (which uses the I2C "Wire" library), you have to have a #include "Wire.h" in your main sketch even though that sketch never accesses Wire function directly, because otherwise the ds1307 library has no idea where the wire library might be.

If the "top-level" of the library directories (/libraries and /Arduino/libraries, I guess) were put in the Include search paths WHEN COMPILING USER LIBRARIES, the libraries could easily do "#include "Wire/Wire.h"" to get their secondary dependancies, without having to rely on the end users knowing about them.

(Offhand, it seems like it would be a bad idea to include these paths for non-user-library compiles, but I can't quite quantify why...)

[matthijskooijman]

I don't think modifying the include path will fix your problem - The ds1307 library will then compile, but the final link will fail, since the Wire library is not included in the link by the IDE. See #2173 for another approach to fixing this.

[Jeppedy]

I did not find the Report 2173 relevant to the issue at hand.

I believe the issue is a very straightforward one from a user perspective. The IDE doesn't process includes the way one would assume based on decades of CPP compiler use.
If I have a #include in a library, and I reference that include in my sketch, that should be all I need. Unfortunately, the IDE fails it, requiring me to add a #include into my sketch that my sketch doesn't even know it needs... (And in fact, it doesn't, at least directly).
In my case, I'm using an RF24 lib, which needs SPI. It's forcing me to #include SPI.H in my sketch, even though my sketch has no direct need for SPI.h content...

If there is something improper about my expectation, please let me know how I should be handling libraries more appropriately.

[matthijskooijman]

Seems I made a typo, I suspect I meant to reference #2174. In any case, this is a known limitation which is fixed by the (now outdated) #2174 and might be fixed by the new preprocessor @ffissore was working on.

I think the original problem presented in this issue is a duplicate of #236, even though the original solution proposed would not solve it. I'm closing this issue in favour of that one.