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.
3 Likes
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.