PaulS:
It is totally brain dead to base the include path for everything
based on the headers "noticed" in the users sketch, particularly when it comes to libraries.I disagree with this. The advantage to listing all libraries in the sketch is that it makes it easy to see, looking at a sketch what libraries it needs.
If a sketch only needed to show that it needed library A, and library A needed libraries B, C, and D, and library C needed libraries E, F, and G, and library E needed 6 more levels of libraries, finding all the needed libraries would be a nightmare.
As it is, a sketch must list all libraries that it needs, so one can see at a glance what libraries will be needed.
One library can NOT hide the fact that it is dependent on another library.
It is not a nightmare. Finding and resolving references is what the linker does.
Libraries are supposed to be independent entities whose modules can be compiled and archived into the library
archive independently.
By creating a system that requires an application to set up things a certain way in its source code
in order to be able to compile a library module the independence is broken.
This defeats the entire point of having a library. It is no longer really a library at that point.
And that is why having the include path used for compiling a library module be determined
by the sketch/application is a totally brain dead thing to do.
The way this should work (and does in other environments) is that library modules are compiled
and archived into a library archive independently from application code.
An application includes only the headers that it needs.
The app is compiled and then linked against library archives and any library functions needed
are pulled in from the archive by the linker.
If a library function called by the application needs another library function,
then those additional functions are also pulled in by the linker.
The application does not and should not have to be aware of the additional library dependencies
of the library functions the application uses.
Imagine how painful things would be if you had to do this include stuff to set up things in "normal" applications.
Can you imagine how many headers you would have to include in your windows app code and how long
it would take to build everything?
The arduino system has a system of extensible libraries. If the IDE and build process were done differently
then all the modules in each library would be built once (or whenever a library module was updated/added)
and archived into a library vs being built every single time the sketch is compiled.
Then a sketch would include only the headers it needs.
The sketch would be linked against the Arduino library archive and the needed references would be resolved.
It would not matter if the references were from the sketch or from a library module that the sketch pulled in.
The problem is that the IDE is simply not treating the libraries as a proper library.
If it did, then these kinds of interdependencies would go way and sketch building would
be much faster since only the modules that changed would need to be re-compiled and archived rather
than having to build every single module used by the sketch and its libraries.
--- bill