mirror of
https://github.com/apache/nuttx.git
synced 2026-08-14 17:03:29 +00:00
0735bc16b9
drivers/ is built by a single flat Makefile: every per-directory Make.defs appends its sources to one CSRCS list and its directory to one VPATH, and the objects all land in drivers/ named after the source basename. Two sources with the same basename in different subdirectories therefore map to the same object, and make resolves the prerequisite through VPATH, which is searched in the order drivers/Makefile includes the Make.defs files. lcd is included before leds, so drivers/lcd always wins. Both apa102 and max7219 exist twice, once as an LCD front-end and once as an LED driver: drivers/lcd/apa102.c CONFIG_LCD_APA102 drivers/leds/apa102.c CONFIG_LEDS_APA102 drivers/lcd/max7219.c CONFIG_LCD_MAX7219 drivers/leds/max7219.c CONFIG_LEDS_MAX7219 drivers/lcd/Make.defs puts lcd on the VPATH for the whole directory whenever CONFIG_LCD=y, so selecting only the LED driver still builds apa102.o from drivers/lcd/apa102.c and the selected LED driver is never compiled at all. Because the LCD front-ends take their constants from include/nuttx/lcd/apa102.h and include/nuttx/lcd/max7219.h, which are behind CONFIG_LCD_APA102 / CONFIG_LCD_MAX7219, the substituted source does not even compile. With CONFIG_LCD=y + CONFIG_LEDS_APA102=y and CONFIG_LCD_APA102 unset: lcd/apa102.c:701:20: error: 'APA102_BLACK' undeclared (first use in this function); did you mean 'APA102_BPP'? and correspondingly for CONFIG_LEDS_MAX7219 without CONFIG_LCD_MAX7219: lcd/max7219.c:773:20: error: 'MAX7219_BLACK' undeclared (first use in this function); did you mean 'MAX7219_BPP'? So neither LED driver can be built together with CONFIG_LCD, and there is no diagnostic pointing at the real cause. Give the LCD front-ends distinct basenames. The LCD side is the adapted use of these parts (an LED matrix driven as a display), and drivers/lcd already names such variants for their role, e.g. ht16k33_14seg.c, so the suffix goes there and the LED drivers keep the plain part names. The CMake build derives object paths from the source directory and was never affected; its source lists are updated to match. Signed-off-by: Ricard Rosson <ricard@groundbits.com> Assisted-by: Claude Opus 5 (Claude Code) |
||
|---|---|---|
| .. | ||
| actions | ||
| ISSUE_TEMPLATE | ||
| linters | ||
| scripts | ||
| workflows | ||
| CODEOWNERS | ||
| dependabot.yml | ||
| gcc.json | ||
| labeler.yml | ||
| membrowse-targets.json | ||
| nxstyle.json | ||
| PULL_REQUEST_TEMPLATE.md | ||
| SECURITY.md | ||