add call to cu_pkg_define_version

[dannybackx]

Related area

support users

Hardware specification

N/A

Is your feature request related to a problem?

My problem was turned down but resolution of my problem not only requires you to call cmake_utilities from esp_lvgl_port so its version numbers are defined in the build system.
See #712.

Describe the solution you'd like

add

include(package_manager)
cu_pkg_define_version(${CMAKE_CURRENT_LIST_DIR})

to esp_lvgl_port, so your users don't have to edit an imported component to get this

Describe alternatives you've considered

See #712. Was turned down but the replacement action should be this feature request, and to my knowledge this wasn't taken up.

Additional context

No response

I have checked existing list of Feature requests and the Contribution Guide

• I confirm I have checked existing list of Feature requests and Contribution Guide.

[github-actions]

Hi @dannybackx! Please be aware that (1) the following suggestions are generated by a bot and haven't been fact-checked by Espressif Systems, (2) burning eFuses and enabling security features are irreversible operations and can damage your ESP32 device. We hope that this message will help you until an Espressif Engineer looks at your issue.

---

You are right that some Espressif components already use cmake_utilities’ cu_pkg_define_version so their version is available to the build system (for example, ble_ota, usb_stream, knob). [Cmake utilities; BLE OTA changelog]

The cmake_utilities component provides:

• cu_pkg_define_version (and cu_pkg_get_version) via package_manager.cmake, intended exactly for this purpose. [CMake utilities doc; Cmake utilities v0.1.0]

Other components in esp-iot-solution/esp-bsp have already adopted this pattern:

• ble_ota: “Use cu_pkg_define_version to define the version of this component.” [BLE OTA changelog]
• usb_stream: same note in its changelog. [usb_stream changelog]
• knob: “Use cu_pkg_define_version to define the version of this component.” [knob changelog]

For esp_lvgl_port specifically, the available docs and changelog only describe LVGL integration features and IDF/LVGL version constraints; they do not show any existing use of cmake_utilities or cu_pkg_define_version in this component. [esp_lvgl_port registry; esp_lvgl_port changelog]

So, based on the current information:

• Your request is consistent with how other Espressif components already expose their version via cu_pkg_define_version.
• There is no indication yet that esp_lvgl_port has adopted this pattern.

A concrete proposal you can post on the GitHub issue (or PR) is:

1. Add cmake_utilities as a dependency in components/esp_lvgl_port/idf_component.yml (if not already present), for example:

   dependencies:
     espressif/cmake_utilities: "0.*"

2. In components/esp_lvgl_port/CMakeLists.txt, after idf_component_register(...), include the package manager and define the version:

   include(package_manager)
   cu_pkg_define_version(${CMAKE_CURRENT_LIST_DIR})

This would align esp_lvgl_port with other components that already use cu_pkg_define_version, and avoid forcing users to patch imported components just to get the version into the build system.

The knowledge sources do not mention any downside or conflict with this approach for esp_lvgl_port, but they also do not confirm that the maintainers have accepted or planned this change yet, so it still needs maintainer review and approval.