The question is then, does it only compile the modules required for a particular situation? Or to what extent does it incorporate code which is not needed?
That is the real question posed by bkucenski.
The answer to that is also, It depends.
I can provide some additional color on that.
(This is from memory, so the exact numbers may be a bit off)
Only compiling the modules needed isn’t the issue as the gcc compiler & linker have had the ability to be told to eliminate unused functions & data for quite some time and the Arduino IDE enables this.
However, there are cases that depending on how the code is written, unused referenced code & data is still pulled in.
The amount of dead wood code & data can vary depending on the version of gcc used and if/how virtual functions are used or if the code is assigned to an interrupt vector.
The ability to prune out unused functions does still exist.; however, the more recent versions of gcc have removed the ability to prune out unused virtual functions as the specific compiler & linker flags to deal with virtual functions (which were not enabled by the Arduino IDE), and linker code have now been removed from gcc.
IMO, this makes using virtual functions very expensive unless you really really need runtime binding which is not something needed or typically ever used in an embedded environment.
IMO, it relegates virtual functions to being a convenience capability that helps out from a s/w maintenance perspective, but there are other C++ techniques that can be used to offer the same capabilities that don’t suffer the dead wood code issue.
At the time I wrote the hd44780 code, I didn’t realize the virtual function dead wood code issue.
The ISR issue can be resolved with clever use of weak attributes, but the Arduino core & bundled libraries don’t do that so if an used Arduino supplied library, like say Wire is linked in, it will drag in all the code even if the sketch never references it.
i.e. including <Wire.h> will include the Wire code even if it is not used by the sketch.
This trips up certain libraries like fm’s newLiquidCrystal as it links in all the i/o classes regardless of which is actually used by the sketch.
The library manager LiquidCrystal_I2C library is a bare bones library that must have the i2c address configured and is hardcoded to a particular pin mapping between the PCF8574 and the LCD. It doesn’t work with several of the software i2c libraries.
If that works for the needed application, it will be the smallest amount of code and includes very little dead wood code.
fm’s newLiquidCrystal compiles all the i/o classes and links them in regardless of them being used and do to poor coding in other Arduino library code referenced, there is few k of unused code that can be dragged in that is unused and unrelated to the i/o class being used. This is not related to the virtual function issue. This is mainly an issue when not using an i2c based device as the Wire library code and data is always linked in regardless of whether it is used by the sketch.
hd44780 only compiles and links in the i/o class that is used by the sketch.
hd44780 with the hd44780_I2C i/o class for an application like a PCF8574 based backpack does end up dragging in around 1.5k or so of uneeded code from a combination of the virtual function issue and the auto chip detect code to determine PCF8574 of MCP23008 and then the MCP23008 support code.
I’m fully aware of these issues and do have plans to resolve this by refactoring the code get around the virtual function issue so that only code that is actually used/referenced is linked in.
I have also been tossing around the idea of releasing a new separate slimmed down library that is just for PCF8574 based backpacks.
I think this could make things even easier for users (especially non English speaking users) since there would be, less documentation to read, no confusion over i/o classes and the code could be even smaller than a refactored hd44780_I2Cexp i/o class as there would be no code to detect and handle other chips
I haven’t had the time to work on it.