lvgl/lv_font_conv

Cpp compiler error with lvgl version 8.x

fvanroie opened this issue · 4 comments

In the generated font source files, there is a section:

#if LV_VERSION_CHECK(7, 4, 0) 
    .underline_position = -1,
    .underline_thickness = 1,
#endif

This block evaluates to true on versions 7.4.0 or higher, but is false on versions from 8.0.0 or higher (different major version).

With lvgl version 8, if the file is compiled as cpp, the order of the fields becomes non-sequential and the compiler throws an error:

Compiling .pio/build/d1-mini-esp32_ili9341/src/font/latin1/robotocondensed_regular_16_latin1.cpp.o
src/font/latin1/robotocondensed_regular_16_latin1.cpp:2583:1: sorry, unimplemented: non-trivial designated
initializers not supported
*** [.pio/build/d1-mini-esp32_ili9341/src/font/latin1/robotocondensed_regular_16_latin1.cpp.o] Error 1
========================================= [FAILED] Took 4.83 seconds =========================================

If I change the #if block to include v8 then that font file compiles fine, because the fields are sequential again:

#if LV_VERSION_CHECK(7, 4, 0) || LV_VERSION_CHECK(8, 0, 0)
    .underline_position = -1,
    .underline_thickness = 1,
#endif

Would it be possible to add the || LV_VERSION_CHECK(8, 0, 0) to this check so the source files compile without change in v8 using cpp ?

Platform:

PLATFORM: Espressif 32 (3.3.0) > WeMos D1 MINI ESP32
HARDWARE: ESP32 240MHz, 320KB RAM, 4MB Flash
DEBUG: Current (esp-prog) External (esp-prog, iot-bus-jtag, jlink, minimodule, olimex-arm-usb-ocd, olimex-arm-usb-ocd-h, olimex-arm-usb-tiny-h, olimex-jtag-tiny, tumpa)
PACKAGES: 
 - framework-arduinoespressif32 3.10006.210326 (1.0.6) 
 - tool-esptoolpy 1.30100.210531 (3.1.0) 
 - toolchain-xtensa32 2.50200.97 (5.2.0)

@kisvegabor how to fix that for current and next major versions at once?

#if LV_VERSION_CHECK(7, 4, 0) || LVGL_VERSION_MAJOR >= 8 should work, as that will target 7.4-7.11 and anything newer than and including 8.0.

Thanks!

I'm a little bit late, but I also agree with @embeddedt's suggestion.