Summary
The cached ESP8266 Arduino core is missing the littlefs git submodule, so any sketch that reaches <LittleFS.h> fails to compile. FastLED's esp8266 badge is red on master because of this.
libraries/LittleFS/src/LittleFS.h:38:10: fatal error: ../lib/littlefs/lfs.h: No such file or directory
38 | #include "../lib/littlefs/lfs.h"
Evidence
The directory exists and is empty — the signature of a submodule that was never initialised:
$ ls -la ~/.fbuild/prod/cache/platforms/esp8266-Arduino/<hash>/3.1.2/Arduino-3.1.2/libraries/LittleFS/
examples/ lib/ library.properties src/
$ ls -la .../libraries/LittleFS/lib/littlefs/
total 0
drwxr-xr-x ./
drwxr-xr-x ../
# <- empty
esp8266/Arduino carries libraries/LittleFS/lib/littlefs as a submodule pointing at littlefs-project/littlefs. A plain archive download or a git clone without --recurse-submodules produces exactly this: the directory is created, the contents are not.
libraries/LittleFS/src/ does contain lfs.c and lfs_util.c, which makes the breakage look stranger than it is — the sources are vendored, the headers are not.
Impact
Anything using LittleFS on ESP8266. It is not FastLED-specific — the failure is inside the core's own header, before any user code is reached. Worth checking whether other cores fbuild packages have submodules in the same position; the failure mode is silent until something includes the affected header.
Note that __has_include(<LittleFS.h>) passes here, so the usual capability guard does not protect against it: the header is present and the thing it needs is not. Consumers cannot detect this from the preprocessor.
Suggested fix
Fetch cores with submodules (git clone --recurse-submodules, or use the release tarball that bundles them), and consider a post-unpack sanity check that a core's declared library headers actually resolve — an empty submodule directory is cheap to detect at package time and expensive to diagnose at compile time.
Workaround in FastLED
ESP8266 embedded-flash storage is now opt-in behind FASTLED_ESP8266_EMBEDDED_FS rather than automatic, so the default build stops hitting this. It can go back to automatic once the core packages correctly.
Related: #1371 (framework-library include resolution), FastLED/FastLED#4006.
Summary
The cached ESP8266 Arduino core is missing the
littlefsgit submodule, so any sketch that reaches<LittleFS.h>fails to compile. FastLED'sesp8266badge is red on master because of this.Evidence
The directory exists and is empty — the signature of a submodule that was never initialised:
esp8266/Arduinocarrieslibraries/LittleFS/lib/littlefsas a submodule pointing atlittlefs-project/littlefs. A plain archive download or agit clonewithout--recurse-submodulesproduces exactly this: the directory is created, the contents are not.libraries/LittleFS/src/does containlfs.candlfs_util.c, which makes the breakage look stranger than it is — the sources are vendored, the headers are not.Impact
Anything using
LittleFSon ESP8266. It is not FastLED-specific — the failure is inside the core's own header, before any user code is reached. Worth checking whether other cores fbuild packages have submodules in the same position; the failure mode is silent until something includes the affected header.Note that
__has_include(<LittleFS.h>)passes here, so the usual capability guard does not protect against it: the header is present and the thing it needs is not. Consumers cannot detect this from the preprocessor.Suggested fix
Fetch cores with submodules (
git clone --recurse-submodules, or use the release tarball that bundles them), and consider a post-unpack sanity check that a core's declared library headers actually resolve — an empty submodule directory is cheap to detect at package time and expensive to diagnose at compile time.Workaround in FastLED
ESP8266 embedded-flash storage is now opt-in behind
FASTLED_ESP8266_EMBEDDED_FSrather than automatic, so the default build stops hitting this. It can go back to automatic once the core packages correctly.Related: #1371 (framework-library include resolution), FastLED/FastLED#4006.