After compilation the compiler shows among others this message:
Dependency Graph
|-- <TFT_eSPI> 2.3.70
| |-- <SPIFFS> 1.0
| | |-- <FS> 1.0
| |-- <FS> 1.0
| |-- <SPI> 1.0
What is it telling me?
Are all these libraries automatically included? OR
Do I have to include them myself because TFT_eSPI needs them.
The only one TFT_eSPI.h includes is: 'SPI.h>
The dependency graph in you post, which I edited to wrap the graph in code format, shows you the various libraries that the library dependency finder, found. They will be automatically included.
The library.json file for a library lists its dependencies. Those may also have dependencies, and so on.
In case you are not aware, a header file, *.h, is not a library! Adding a library in the Arduino IDE gives you this impression because that’s what appears to happen. The header file simply tells the compiler that your code wishes to let it know that at some point it may see various function, supplied by the library, and what the function names are, their return type and parameter names and types.
The C/C++ compiler needs to know what a function “looks like”, whether in your code or a library, before it can be used by your code. The Arduino IDE doesn’t mind as it tries to sort out the functions you didn’t supply a description (prototype) for, and fills them in automagically.
The Arduino compilation process is described here. FYI.
Cheers,
Norm.
Norman,
Thank you, that clears the sky.
BTW, don’t be modest: just say you wrote an informative book and fill in a gap for a lot of people.
My guess is that the compilation process is just the same when using the platformIO IDE.
I looked up ‘TFT_eSPI/library.json at master · Bodmer/TFT_eSPI · GitHub’, but to my surprise; no dependencies mentioned.
PlatformIO’s library dependency finder (LDF) does not only include dependencies declared in a library’s library.json (if that exists at all), but it also auto-scans the library code for #include <header.h> lines and attempts to deduce the needed dependencies that way. So SPIFFS and FS are included because it sees
PlatformIO docs for that are at Library Dependency Finder (LDF) — PlatformIO latest documentation. Note that PlatformIO has different levels of “smartness” selectible when identifying dependencies – see lib_ldf_mode.
The dependency graph shows you the “is” state of detected libraries (and their dependencies). It does not tell you what you need to include for something to work (“should” state), it tells you purely what it included. In this case you should have no problems because the all dependencies have been identified correctly. On the other hand, if you know that a library e.g. has the Wire (I2C) library as a dependency, but it isn’t showing up in the dependency graph and you get a “can’t find Wire.h” error, that’s an indication of PlatformIO not having identified the libraries correcty, after which you must e.g. use the above mentioned lib_ldf_mode or massage the LDF into doing the right thing by writing an #include <missing lib.h> in your main source file.
I don’t wish to spam the forums with plugs for it. If people are interested, they’ll find it!
Similar. The full PlatformIO build process – which I’m not familiar with yet, as it’s Python – does some background work on your behalf – installing libraries, finding dependencies (as @maxgerhardt points out) and so on. But in the final compilation phase, those libraries are compiled into a static library and linked by the linker to produce the final *.elf file which is then converted to a *.hex file for uploading.
However, where the Arduino IDE will attempt to insert the “missing” function prototypes so that the compiler knows about them before use; or add the “Arduino.h” to the sketch if it’s missing, PlatformIO doesn’t. It’s the responsibility of the developer to make sure that functions are declared ahead of time and that all the required header files are included.
Cheers,
Norm.
Thank you,
So, when I understand this correct; Python does the heavy lifting of creating the translation file and after that, the GCC compiler kicks in.
Does that also mean that the bulk load of messages that occurs when building an application, comes from Python?
I believe so. After the compiler has done its thing, the linker compines all the object files with all the libraries to create an *.elf file. That gets converted to *.hex and *.eep ready for upload. Assuming no errors.
That would depend on what the errors are. Things like duplicate definitions, syntax errors, unused variables, missing functions etc would be from the compiler, undefined function names are most likely the linker (with error 1 or error 2 usually).
Missing libraries, dependency graphs would be python, from the Library Dependency Finder. Informative messages during the build would most likely be from the various Python “stuff”.
Cheers,
Norm.