Link the Arduino component automatically when built as an ESP-IDF component - #344
Merged
Merged
Conversation
…ponent arduino-esp32 publishes its -DARDUINO... definitions as PUBLIC compile options, so they only reach components that link against it. The public headers of this library change class layout with ARDUINO (LGFXBase derives from Print only under ARDUINO, for example), so an application built with arduino-esp32 as a component read the same objects with a different layout than this library was compiled with: getPanel() returned null and drawing faulted. Pick the Arduino component that is already part of the build (arduino / arduino-esp32 / espressif__arduino-esp32, overridable with <LIB>_ARDUINO_COMPONENT, OFF to disable) after register_component() and link it publicly. Only BUILD_COMPONENTS is consulted, so a build that excludes Arduino is unaffected, and only APIs that exist since ESP-IDF 4.x are used.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Problem
When arduino-esp32 is used as an ESP-IDF component, its
-DARDUINO=...definitions are exported asPUBLICcompile options of the Arduino component, so they only reach components that link against it — the application (main) does, this library did not. The public headers of this library change class layout withARDUINO(for exampleconfig_thasserial_baudrateonly underARDUINO, and the display object it embeds changes size), so the application read the same objects with a layout different from the one the library was compiled with:getPanel()returned null and the first drawing call faulted.The
CMakeLists.txtalready carried the fix as a commented-out line (list(APPEND COMPONENT_REQUIRES arduino-esp32)), but a user of the component registry cannot enable it.Change
After
register_component(), look for an Arduino component among the components selected for the build (arduino,arduino-esp32orespressif__arduino-esp32) and link itPUBLIC, so this library is compiled with the same definitions as the application. OnlyBUILD_COMPONENTSis consulted: a build that does not contain Arduino, or excludes it withCOMPONENTS/EXCLUDE_COMPONENTS, is unaffected. Only APIs available since ESP-IDF 4.x are used. This is the same pattern arduino-esp32 itself uses for its optional dependencies (maybe_add_component).M5UNIFIED_ARDUINO_COMPONENT=<name>selects a differently named Arduino component;M5UNIFIED_ARDUINO_COMPONENT=OFFdisables the automatic dependency.FATAL_ERRORwith the variable to set).Note for hybrid projects: once Arduino is part of the build, every component that includes this library's headers now compiles them in Arduino mode, which is what the application already did.
Verification
getPanel()is null and the panel is never initialised; with it the display works. SettingM5UNIFIED_ARDUINO_COMPONENT=OFFrestores the old behaviour, a custom name and an empty value behave as documented.