esp-rs/esp-idf-template

Project generated with esp-idf-template fails clippy checks on CI

slackinghyena opened this issue · 4 comments

Bug description

I created a new cargo project, committed it on github and the clippy checks on CI are failing with the following message:

error: failed to run custom build command for `esp-idf-sys v0.33.3`

Caused by:
  process didn't exit successfully: `/home/runner/work/sensors/sensors/target/debug/build/esp-idf-sys-910[352](https://github.com/antogilbert/sensors/actions/runs/6577589135/job/17869551577#step:5:353)40eb6b44d0/build-script-build` (exit status: 1)
  --- stdout
  cargo:rerun-if-env-changed=ESP_IDF_TOOLS_INSTALL_DIR
  cargo:rerun-if-env-changed=ESP_IDF_SDKCONFIG
  cargo:rerun-if-env-changed=ESP_IDF_SDKCONFIG_DEFAULTS
  cargo:rerun-if-env-changed=MCU
  cargo:rerun-if-env-changed=ESP_IDF_SYS_ROOT_CRATE
  Installer version: 1.1.2
  Platform: Linux-6.2.0-1014-azure-x86_64-with-glibc2.35
  Python version: 3.10.12 (main, Jun 11 2023, 05:26:28) [GCC 11.4.0]

[... Some pip install output ...]

--- stderr
  Build configuration: BuildConfig {
      esp_idf_tools_install_dir: None,
      esp_idf_sdkconfig: None,
      esp_idf_sdkconfig_defaults: None,
      mcu: Some(
          "esp32",
      ),
      native: NativeConfig {
          esp_idf_version: None,
          esp_idf_repository: None,
          esp_idf_cmake_generator: None,
          idf_path: None,
          extra_components: [],
          esp_idf_components: None,
          esp_idf_component_manager: None,
      },
      esp_idf_sys_root_crate: None,
  }
  Error: Compatible PlatformIO Core not found.
  Reason: PlatformIO executable not found in `/home/runner/work/sensors/sensors/.embuild/platformio/penv/bin`
  Error: MCUs mismatch: configured MCU 'esp32' does not match MCUs [ESP32], which were derived from the build target 'xtensa-esp32-espidf'

This happens also if i run the clippy command manually. I tried with these two docker images when running locally:
espressif/idf-rust:esp32s3_latest
espressif/idf-rust:esp32_latest

  • Would you like to work on a fix? [y/n] Yes, if mentored

To Reproduce

Steps to reproduce the behavior:

  1. docker run --rm -it espressif/idf-rust:esp32s3_latest bash
  2. cargo install cargo-generate
  3. USER=antogilbert cargo generate esp-rs/esp-idf-template
  4. Use these values in the wizard:
  • ✔ 🤷 Which template should be expanded? · cargo
  • 🤷 Project Name: sensors
  • 🔧 Destination: /home/esp/sensors ...
  • 🔧 project-name: sensors ...
  • 🔧 Generating template ...
  • ✔ 🤷 Which MCU to target? · esp32
  • ✔ 🤷 Configure advanced template options? · true
  • ✔ 🤷 Enable STD support? · true
  • ✔ 🤷 Configure project to use Dev Containers (VS Code and GitHub Codespaces)? · true
  • ✔ 🤷 Configure project to support Wokwi simulation with Wokwi VS Code extension? · true
  • ✔ 🤷 Add CI files for GitHub Action? · true
  • ✔ 🤷 ESP-IDF version (master = UNSTABLE) · v5.1
  1. cd sensors
  2. cargo clippy --all-targets --all-features --workspace -- -D warnings

Expected behavior

Generated project should not fail clippy checks.

Environment

inside the following two containers:

espressif/idf-rust:esp32s3_latest
espressif/idf-rust:esp32_latest

Can you please NOT do --all-features? Or remove the pio feature if you really insist?

@ivmarkov removing pio worked. Thanks. However, just for clarity, I have simply generated the repo with the wizard provided by the esp-rs/esp-idf-template, I haven't created the CI files myself or modified anything. Is there a reason why pio fails the clippy checks?

My suspicion is that it is just a case of case sensitive comparison, where it should be case insensitive. Let me check that quickly...

OK, I've released new patch-level releases of both embuild and esp-idf-sys.
Just do cargo update and the problem would be fixed.

As to why you probably don't want --all-features - the native and pio features are kind of mutually exclusive, as you can either build the ESP IDF using the native CMake ESP IDF build, or by using PlatformIO. When you specify --all-features what happens is that the pio build will prevail, as it is the non-default option that overrides native.

pio based build only supports whatever ESP IDF version is supported by the latest PlatformIO though, and does not have many of the configuration options the native build has.