July 21, 2022 at 00:26 #32851
In my application I need to include a dependency to a component from the espressif repository: https://components.espressif.com/
When I build the project, the toolsuite detects the dependency but cannot update the component because it says that the component manager has not been enabled.
CMake Warning at C:/SysGCC/esp32/esp-idf/v4.4.1/tools/cmake/build.cmake:482 (message):
“idf_component.yml” file was found for components:
However, the component manager is not enabled.
What is the procedure to enable the Component Manager?
I use Visual Studio 2019 16.11.17 / VisualGDB-5.6R6-4622 / Toolchain 8.4.0/8.1.0/r9 / ESP-IDF v4.4.1
Thank you very much.July 21, 2022 at 08:14 #32853
This looks like an error coming from the ESP-IDF build system and not something specific to VisualGDB. Please refer to the ESP-IDF documentation for more details on it.
If you can build the same project outside VisualGDB, but not with VisualGDB, please follow the troubleshooting instructions here to get it working.July 28, 2022 at 02:30 #32876
Yes, I understand that this is not a VisualGDB issue, but I am asking how I can configure the Espressif toolsuit that comes with VisualGDB so that the component manager is enabled.
In the official Espressif IDE we have the “ESP-IDF 4.4 CMD” where we can work from the command line.
In this CMD we can execute the following command to enable the component manager:
pip install idf-component-manager –upgrade
And in the configuration of the project with dependencies developed with the Espressif-IDE we can define IDF_COMPONENT_MANAGER environment variable:
My question is how can I build a project that has dependencies?
Thank you very much.July 28, 2022 at 03:11 #32879
gojimmypiParticipantJuly 28, 2022 at 04:34 #32885
I have already found the solution.
On the website idf-component-manager it says:
Starting ESP-IDF v4.4 the idf-component-manager package is installed by default and no extra action is necessary.
Since I use v4.4.1 I don’t need to run the pip command.
To enable the component manager in the project configuration phase, you must add the following variable in the CMakeLists.txt of the project root:
In this way, in the configuration phase, when the idf_component.yml file is found in the main component, the dependency is executed and the referenced component is downloaded:
Solving dependencies requirements
Updating lock file at C:/Users/user/Documents/Tmp/espressif/mb_slave\dependencies.lock
Processing 2 dependencies:
[1/2] espressif/esp-modbus (1.0.4)
[2/2] idf (4.4.1)
— DEBUG: Use esp-modbus component folder: C:/Users/user/Documents/Tmp/espressif/mb_slave/managed_components/espressif__esp-modbus.
This is very important because the freemodbus component has been moved to a separate esp-modbus repository from v5.0.July 30, 2022 at 21:37 #32902
Thanks for sharing this. It indeed looks like a change in ESP-IDF structure and not something VisualGDB would handle automatically. That said, if you do not want to edit the CMakeLists files manually, you can always specify the extra environment variables via the VisualGDB GUI as shown below:June 7, 2023 at 15:24 #34339
I’ve setup wolfSSL as a managed component.
I’m hoping to use other components such as the esp-cryptoauthlib.
Components are added to a project like this:
idf.py add-dependency "espressif/esp-cryptoauthlib^3.5.1~1"
It appears the only thing that command does is to add/update the project
Subsequent calls with
idf.py buildappear to recognize that component file, download required files to the
managed_componentsdirectory, and compile everything.
However, from within the VisualGDB environment, nothing new seems to happen at compile time: The IDE does not seem to recognize the ESP Registry components in the
I wasn’t able to find any VisualGDB documentation on this. It this capability supported? I’m using EDP-IDF v5.
Thank youJune 8, 2023 at 08:15 #34344
You can export the build commands used by VisualGDB via the “Dump command line to batch file” command as shown on this page. This should allow you to reproduce the build problem outside VisualGDB and compare the command lines between the working and non-working build.
Our best guess is that some environment variables or other minor parameters are slightly different between the 2 builds.
You must be logged in to reply to this topic.