Build error on latest lv_micropython. "add_executable command is not scriptable". Fix workaround provided, not sure how to suggest long term fix or something else

aseelye · July 19, 2021, 7:10pm

Hi all,

Posting here as perhaps I’m not the only one having this trouble. I’ve been having a rough go at building the latest lv_micropython. I’ve installed this on a fresh debian stable build, with ESP-IDF v4.2. I’m able to pull the repo and build mpy-cross, but when it comes to building the esp32 firmware, I get the above error. I’ve found, however, that updating cmake from buster-backports from version 3.13 to 3.16 fixes the cmake errors and builds the image properly.

I’m not sure at this point if this is just a documentation change, or if it’s the intent of the lv_micropython repo maintainers to keep things current with Debian (and perhaps other derivative distributions). If any of the repo maintainers read this and would like some further details, screenshots, whatever, let me know.

embeddedt · July 19, 2021, 7:36pm

As far as I know, you are expected to update CMake for the build to work properly, however, I’m not sure that this is documented clearly enough. I couldn’t find a mention of it on the main README or on the ports/esp32 README. @amirgon?

amirgon · July 19, 2021, 7:54pm

Currently the minimal required version of CMake is 3.12:

github.com

lvgl/lv_micropython/blob/846a2f3001f5034237f2efd7664ca90250cc31d4/ports/esp32/CMakeLists.txt#L3

    
      
          # Top-level cmake file for building MicroPython on ESP32.
          
          
cmake_minimum_required(VERSION 3.12)
          
          
# Set the location of this port's directory.
          set(MICROPY_PORT_DIR ${CMAKE_SOURCE_DIR})
          
          
# Set the board if it's not already set.
          if(NOT MICROPY_BOARD)
              set(MICROPY_BOARD GENERIC)
          endif()
          
          
# Set the board directory and check that it exists.

Maybe it should be set to a higher version, but I’m not sure yet.
add_executable command is supported by CMake 3.12 and higher so I’m not sure why you are getting this error.

@aseelye Could you show us the full error you are getting including line numbers etc.? Maybe there were some previous errors you missed? Does it happen only with lv_micropython or also with upstream micropython?

aseelye · July 20, 2021, 3:42pm

Mainline micropython builds successfully. Both outputs linked.

Build output for lv_micropython: lv_micropython build fail · GitHub

Build output for mainline micropython (successful): micropython build · GitHub

amirgon · July 20, 2021, 8:42pm

Thanks you for the logs @aseelye.

It may be related to this problem:

github.com/espressif/esp-idf

CMake: Source Code Generation fails with "add_custom_command command is not scriptable" (IDFGH-2427)

opened 02:56PM - 23 Dec 19 UTC

closed 01:59PM - 19 Feb 20 UTC

mringwal

Hi I need to generate source code as part of the build process. In the cur…rent documentation, the use of the CMake add_custom_command" is recommended: https://docs.espressif.com/projects/esp-idf/en/latest/api-guides/build-system.html#source-code-generation However, if I add this to esp-idf/example/get-started/blink/main/CMakeLists.txt ``` add_custom_command( OUTPUT logo.h COMMAND echo "test" > logo.h ) ``` and run `idf.py build`, I get this error ``` Make Error at /Projects/esp32/esp-idf/tools/cmake/component.cmake:222 (message): CMake Error at /Projects/esp32/esp-idf/examples/get-started/blink/main/CMakeLists.txt:1 (add_custom_command): add_custom_command command is not scriptable ``` Any ideas on how to run a script to create a source file? Thanks! This is on the current master branch: 30372f5a4ff2c0dfdaad95f544dc36bcdda30b75

Could you try their suggestion?
Just wrap the include to mkrules.cmake with this:

# Include LVGL bindings rules
if(NOT CMAKE_BUILD_EARLY_EXPANSION) 
    include(${MICROPY_DIR}/lib/lv_bindings/mkrules.cmake)
endif()

aseelye · July 22, 2021, 12:04am

The wrapper seems to have done the trick, thank you.

amirgon · July 22, 2021, 7:38am

Thank you for confirming this.
I’ve pushed this fix to lv_micropython.