Generalises the lv_conf.h fix, because it was never an LVGL problem. One
live compile resolved SIX config headers against the shared library dir in a
single build (sdkconfig.h, lv_conf.h, lv_conf_kconfig.h,
lv_rt_thread_conf.h, User_Config.h, zconf.h): six chances to merge a library
nobody asked for, and one of them did exactly that.
The rule is now about the shape of the name (*conf.h, *config.h, *_setup.h,
plus the known ones) and applies only to headers reached TRANSITIVELY -- a
config header the sketch includes itself is intent and still resolves.
Why skipping the lookup is safe rather than merely convenient: once a library
is merged its own headers are on the include path, so a config header shipped
BY the library that asks for it resolves at compile time with no lookup at
all. The lookup can only ever pull in a DIFFERENT library, which for a config
header is never what the project meant. A genuinely missing header now fails
where it should -- named, in the compiler output -- instead of inside the
sources of a library the sketch never mentioned.
Tests cover all six shapes, the direct-include exception and an ordinary
transitive dependency (Adafruit GFX -> BusIO) that must keep merging.
A sketch whose only LVGL include was <lvgl.h> died on a wall of errors from
Adafruit LvGL Glue, a library it never included. LVGL's sources carry
`#include "lv_conf.h"` behind `#if !LV_CONF_SKIP`; the include scan is
textual and does not evaluate that guard, so the header was queued even for a
build defining LV_CONF_SKIP=1, resolved against the shared library dir, and
found the copy the glue library vendors for LVGL v7. That merged the whole
library, whose sources then failed against the LVGL v8 actually in use
('lv_fs_drv_t' has no member named 'user_data').
Same failure shape as the Hash.h -> stemihexapod case already documented
next to it, so the fix is the same: a project-supplied config header never
resolves against user libraries. A project shipping its own lv_conf.h is
unaffected (sketch files are found in the build's own source dir), and a
project that really wants the glue library still reaches it by including
its own header.
Three-part fix for the library-contamination class of ESP32 compile
failures (a user's project kept pulling unrelated libraries because 79%
of projects compile with an empty manifest, forcing scan-all resolution
over ~1000 shared libraries):
1. Name-affinity ranking in _find_library_for_header: the provider whose
name matches the header stem wins (exact normalized match > esp32
arch declaration > contains-stem, alphabetical only as tie-break).
Previously first-alphabetical won, so any stray library shipping a
generic header (Servo.h has 6 providers) could hijack the build.
2. Manifest auto-migration: scan-all compiles now report the libraries
the build really used (manifest_incomplete +
manifest_suggested_libraries on the compile result); the editor folds
single-candidate suggestions into the board's declared manifest after
a green build, so the NEXT compile runs scoped. One green build = one
migrated project; empty-manifest scan-all behaviour is untouched.
3. Install-declares: the Wokwi import library modal records successful
installs in the active board's manifest, and .vlx export/import now
round-trips board.libraries.
Tests: test_espidf_library_ranking.py (9) + library-manifest.test.ts (19).
David Montero