A local library that no include reaches is still compiled, so one platform-specific
library sitting in lib/ breaks builds for every other platform.
Reproduce
A project whose lib/ holds FastLED and Adafruit_ZeroDMA (a SAMD library), and a
sketch that includes only <FastLED.h>:
$ fbuild build -e arduino_avr_uno --no-timestamp
build error: build failed: local library 'Adafruit_ZeroDMA' compilation failed:
build failed: compilation failed for .\lib\Adafruit_ZeroDMA\Adafruit_ZeroDMA.cpp:
lib/Adafruit_ZeroDMA/Adafruit_ZeroDMA.cpp:30:10: fatal error: malloc.h: No such file or directory
#include <malloc.h> // memalign() function
^~~~~~~~~~
compilation terminated.
Nothing in the sketch includes Adafruit_ZeroDMA. It is being compiled for an ATmega328P
because it happens to sit in lib/.
Expected
Compile the libraries the include graph reaches, as #205's LDF-style scanner does for
framework libraries. Local lib/ directories appear not to go through it.
Workaround we run
Every optional library is renamed out of lib/ for the duration of a build and back
afterwards, keyed on the include markers the sketch actually contains. It works, but two
things follow from it: concurrent builds can never share a project directory, and we
cannot move those libraries to lib_deps — which resolves correctly as of 2.5.21, thank
you — because they would be back in the same position.
Environment
fbuild 2.5.21, Windows 11. Found while re-verifying our fbuild integration in
Design Studio for FastLED.
A local library that no include reaches is still compiled, so one platform-specific
library sitting in
lib/breaks builds for every other platform.Reproduce
A project whose
lib/holdsFastLEDandAdafruit_ZeroDMA(a SAMD library), and asketch that includes only
<FastLED.h>:Nothing in the sketch includes
Adafruit_ZeroDMA. It is being compiled for an ATmega328Pbecause it happens to sit in
lib/.Expected
Compile the libraries the include graph reaches, as #205's LDF-style scanner does for
framework libraries. Local
lib/directories appear not to go through it.Workaround we run
Every optional library is renamed out of
lib/for the duration of a build and backafterwards, keyed on the include markers the sketch actually contains. It works, but two
things follow from it: concurrent builds can never share a project directory, and we
cannot move those libraries to
lib_deps— which resolves correctly as of 2.5.21, thankyou — because they would be back in the same position.
Environment
fbuild 2.5.21, Windows 11. Found while re-verifying our fbuild integration in
Design Studio for FastLED.