velxio/test
David Montero 7b5d30791c espidf: never resolve generic platform headers against user libraries
Reported by a user whose every ESP32 build failed with errors from
libraries he never installed (SoftwareSerial.h, ArduinoBearSSL.h,
Adafruit_GFX.h, AsyncElegantOTA.h) coming out of user_libs_all, in a
project whose file list doesn't even show that folder.

Traced end to end: ESPAsyncWebServer includes <Hash.h> (an ESP8266-core
header, guarded for that platform, so arduino-esp32's tree has no such
file). The global scan then resolved it to stemi-hexapod's src/Hash.h --
a hexapod-robot library -- merged the WHOLE library into user_libs_all,
and its Serial.cpp / Hash.cpp / Server.cpp / BluetoothLowEnergy.cpp /
ExpansionDriver.cpp were compiled, each failing on its own unrelated
includes. Log line: 'Merging "stemihexapod" into user_libs_all for
<Hash.h>'.

Hash.h and friends now join the never-resolve-against-user-libs set.
They cannot be discovered by the core-tree scan (the core genuinely
lacks them) yet their names are generic enough that some installed
library owns a file by that name.
2026-08-04 05:23:42 +02:00
..
backend espidf: never resolve generic platform headers against user libraries 2026-08-04 05:23:42 +02:00
esp32_cam Refactor ESP32 library management and add regression tests for issue #129 2026-04-30 23:49:46 -03:00
test_circuit chore(deps): bump the npm_and_yarn group across 1 directory with 4 updates 2026-07-29 23:11:00 +00:00