Auto-detect dependencies between libraries [imported]

[cmaglie]

This is Issue 236 moved from a Google Code project.
Added by 2010-04-29T16:16:24.000Z by follower@gmail.com.
Please review that bug for more context and additional comments, but update this bug.

Original labels: Type-Enhancement, Priority-Medium, Component-IDE

Original description

What change would like to see?

Enable libraries to include other libraries

Why?

AFAIK at present it's not possible for one library to include another library. This makes it difficult
to have, for example, a SPI device with a library that includes a generic SPI communication
library--the SPI library currently needs to be included in the same folder as the device library.

Would this cause any incompatibilities with previous versions? If so, how
can these be mitigated?

It shouldn't.

(I'm reasonably certain this enhancement has been discussed before but I couldn't find an
existing issue for it.)

[martinjos]

Is this still not fixed? I have seen things like "library.json" (e.g. in i2cdevlib) that seem to describe the dependencies, but they do not seem to be used by the Arduino IDE.

I have read the comments on the Google Code issue, particularly the objections about users being unaware of what libraries are drawn in by a given include file.

It has occurred to me that a tree of includes could be shown within the file, like this (greyed out and non-editable, and not saved to file, except the first line):

[-] #include <header1.h>
| [-] #include <header2.h> // from directory2, included by <header1.h>
| |--- #include <header3.h> // from directory3, included by <header2.h>
|--- #include <header4.h> // from directory4, included by <header1.h>

The comments help you to see what includes what, and the plus/minus signs allow you to fold the section up. Perhaps just the one plus/minus sign at the top would be necessary.

[PaulStoffregen]

I worked on this many years ago, when the IDE code was simpler, and had a solution. But the main problem here is not coding, it's a matter of being able to make a decision. So far, there have been numerous discussions, but nobody like David or Cristian has managed to make the final decision.

Without an authoritative decision from Cristian, I'm afraid this is never going to happen.

[martinjos]

But that is why I am making this suggestion. From looking at the old comments, it seems that the main thing that was preventing people from making a decision was the concern that users would not be aware of what was going on behind the scenes. My solution ensures that users will always be aware what libraries are being used, even if they did not explicitly include them. It also protects the user from accidentally deleting any necessary includes (because all but the top line of the tree is not editable, and in any case, it is only a representation of the includes that are present within the header files themselves).

The only question that remains is how to differentiate between different libraries that contain header files with the same names. I would suggest that libraries are required to contain something like #include ARDUINO_LIB <directory1/header1.h>. The angle brackets indicate that the include is external (as usual in C/++), while the macro ARDUINO_LIB (which expands to the empty string) indicates that the Arduino IDE should treat it specially by looking for (compiling, adding to the link path, linking) a library named "directory1". There are no backward compatibility issues with this, as existing libraries cannot include from other libraries anyway. Note that the include search path need only be extended with the "libraries" directories.

I appreciate the previous comments about using the compiler toolchain to traverse the header tree, but unfortunately with traditional C compilers (such as GCC) this is generally prohibitively difficult, and if there is a desire to support multiple toolchains it would mean having to support each one. Until somebody decides to move the Arduino project permanently over to LLVM (which would make this relatively easy, albeit still tied to one toolchain), I would propose to simply extend the existing dependency detection code, which seems to work well enough.

[PaulStoffregen]

seems that the main thing that was preventing people from making a decision was the concern that users would not be aware of what was going on behind the scenes

That was David Mellis, many years ago. By the time he changed his mind, I had moved to a hardware project...

Since then, more discussion happened at least a couple times on the developers mail list. I believe it also ended with indecision, specifically about whether to parse for #include lines, or perhaps get the dependency info from meta data files.

The theme is the same though, ongoing indecision.