Espressif ESP32 Staging Components Preview: fails to find component

[gojimmypi]

Managed components: the regular release versions seem to work fine in VisualGDB. See:

https://docs.espressif.com/projects/idf-component-manager/en/latest/

I’m trying to use the preview / staging Espressif Managed Components, specifically those at this site:

https://components-staging.espressif.com/

In theory, the only thing that should be needed for the staging components is to set the IDF_COMPONENT_REGISTRY_URL environment value to the above link.

I’ve tried setting environment variables, as well as a user variable in Visual Studio. I keep seeing this error that seems to indicate the build process is not looking at the staging site (component not found):

Running CMake: C:\Users\gojimmypi\AppData\Local\VisualGDB\CMake\bin\cmake.exe ../../.. -G "Ninja" -DCMAKE_BUILD_TYPE=DEBUG -DCMAKE_MAKE_PROGRAM=C:/SysGCC/esp32/tools/ninja/1.11.1/ninja.exe -DESP_PLATFORM=1 -DCCACHE_ENABLE=0 -DIDF_TARGET=esp32
-- Configuring for ESP32 variant:
-- Partition table file:
-- Component directory C:/workspace/esp32-homekit-demo-gojimmypi-pr/components/esp-idf does not contain a CMakeLists.txt file. No component will be added
-- Component directory C:/workspace/esp32-homekit-demo-gojimmypi-pr/components/esp32-library does not contain a CMakeLists.txt file. No component will be added
-- Building ESP-IDF components for target esp32
-- Checking Python dependencies...
Python requirements are satisfied.
Constraint file: C:\Users\gojimmypi\.espressif\espidf.constraints.v5.2.txt
Requirement files:
- C:\SysGCC\esp32\esp-idf\v5.2\tools\requirements\requirements.core.txt
Python being checked: C:\SysGCC\esp32-master\python_env\\idf5.2_py3.8_env\Scripts\python.exe
Manifest files have changed, solving dependencies.
CMake Error at C:/SysGCC/esp32/esp-idf/v5.2/tools/cmake/build.cmake:544 (message):
WARNING: Component "gojimmypi/mywolfssl" not found

ERROR: Because project depends on gojimmypi/mywolfssl (^5.7.1-preview2f1)
which doesn't match any versions, version solving failed.

Call Stack (most recent call first):
C:/SysGCC/esp32/esp-idf/v5.2/tools/cmake/project.cmake:605 (idf_build_process)
CMakeLists.txt:44 (project)

.-- Configuring incomplete, errors occurred!
System.Exception: CMake exited with code 1
at s24.e(c a, Object b)

========== Project Configuration Summary ==========
wolfssl_IDF_v5.2_ESP32 configured in 00:07
========== Configuration: 1 Succeeded, 0 Failed, 0 Skipped ==========

Note that I’m using a preview of wolfSSL called “mywolfssl” located at:

https://components-staging.espressif.com/components/gojimmypi/mywolfssl/versions/5.7.1-preview2f1

Otherwise, this all works fine from a Linux prompt for both staging and release components.

I’m using the ESP-IDF v5.2. The command that fails is in C:\SysGCC\esp32\esp-idf\v5.2\tools\cmake\build.cmake. Specifically here:

https://github.com/espressif/esp-idf/blob/9f4f8e24f2235098a022e57927fd1688f62578dc/tools/cmake/build.cmake#L531

When I expand and run the command manually, it looks like this:

python -m idf_component_manager.prepare_components --project_dir=C:/workspace/esp32-homekit-demo-gojimmypi-pr/examples/led --lock_path= --interface_version=2 prepare_dependencies --local_components_list_file=C:/workspace/esp32-homekit-demo-gojimmypi-pr/examples/led/build/VisualGDB/Debug/local_components_list.temp.yml --managed_components_list_file=C:/workspace/esp32-homekit-demo-gojimmypi-pr/examples/led/build/VisualGDB/Debug/managed_components_list.temp.cmake

The exit code is “2”. When manually running it, I see this error:

ERROR: IDF_TARGET is not set, should be set by CMake, please check your configuration

I suppose that error is expected due to the prior failure of finding the required component.

I’m using Visual Studio 2022 with VisualGDB 6.0 installed fresh just today via the Visual Studio prompt.

Thanks in advance for any tips on resolving this.

 

 

[support]

Hi,

If you would like VisualGDB to pass an environment variable to CMake, you would need to set it via VisualGDB Project Properties -> CMake Project -> CMake Command -> Environment.

You can then double-check it by dumping the command used by VisualGDB to a batch file as shown here. The file should contain all environment variables set by VisualGDB and running it should produce the same result as building the project with VisualGDB.

[gojimmypi]

That seemed like a reasonable approach, although I was left wondering why system-wide environment value would not be “seen” by cmake?

In any case, it didn’t work.  (see attached). I still see the error:

Requirement files:
- C:\SysGCC\esp32\esp-idf\v5.2\tools\requirements\requirements.core.txt
Python being checked: C:\SysGCC\esp32-master\python_env\\idf5.2_py3.8_env\Scripts\python.exe
Manifest files have changed, solving dependencies.
..-- Configuring incomplete, errors occurred!
CMake Error at C:/SysGCC/esp32/esp-idf/v5.2/tools/cmake/build.cmake:544 (message):
WARNING: Component "gojimmypi/mywolfssl" not found

ERROR: Because project depends on gojimmypi/mywolfssl (^5.7.1-preview2f1)
which doesn't match any versions, version solving failed.

Call Stack (most recent call first):

Here it is in WSL using the same toolchain; first, the error is expected since there’s no release called mywolfssl

$ idf.py add-dependency "gojimmypi/mywolfssl^5.7.1-preview2f1"
Executing action: add-dependency
ERROR: Component "gojimmypi/mywolfssl" not found

Here it is setting the staging site environment variable:

gojimmypi:/mnt/c/workspace/esp32-homekit-demo-gojimmypi-pr/examples/led
$ export IDF_COMPONENT_REGISTRY_URL=https://components-staging.espressif.com
gojimmypi:/mnt/c/workspace/esp32-homekit-demo-gojimmypi-pr/examples/led
$ idf.py add-dependency "gojimmypi/mywolfssl^5.7.1-preview2f1"
Executing action: add-dependency
Successfully added dependency "gojimmypi/mywolfssl^5.7.1-preview2f1" to component "main"

It then successfully builds using the staging instance of gojimmypi/mywolfssl.

Also, after attempting to build and revisiting the IDF_COMPONENT_REGISTRY_URL=https://components-staging.espressif.com shown in the attached screen snip, when clicking on the newly created IDF_COMPONENT_REGISTRY_URL value, Visual Studio became unresponsive and restarted.

Other than this anomaly, VisualGDB is working great.

Attachments:

You must be logged in to view attached files.

[support]

Hi,

If the components registry is working on WSL, but not on regular Windows, it could be a bug in ESP-IDF. Using ESP-IDF via VisualGDB will not automatically fix it. Please make sure you can build it via Windows command line/batch file before trying to fix it on VisualGDB’s end.

If changing something via VisualGDB GUI crashes Visual Studio, please consider obtaining a call stack of the crash as shown here: https://visualgdb.com/support/callstack

[Author]

Posts