-
Notifications
You must be signed in to change notification settings - Fork 316
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[Bug Report]: Conflict with PlatformIO and ESP-IDF Extension (VSC-456) #190
Comments
We are unable to replicate this in Windows 10, but let me install Windows 7 and test again. BTW as per your steps to reproduce:
Did you try to run the Also we have added |
I performed all the tasks successfully in Onboarding. The idf.customExtraPaths was set appropriately within the settings.json file. When a terminal is opened, %PATH% does show the environment variables you'd expect. Still, when the build button is pushed, it cannot find the esp-idf path to cmake and fails with the error shown previously. Additionally, I have installed the PlatformIO Espressif 32 platform. Perhaps that makes a difference. I will investigate more on my side later on today. Thank you for your efforts. |
... and what about when you run the IDF Terminal command by pressing
@hustlelabs We able to replicate the issues, will fix the same ASAP. Thanks for the bug report!
@hustlelabs For quick unblocking of this issue if possible please uninstall the platformio extension, since due to conflicting paths/configs injecting into the We will investigate this issue further and keep you posted |
When I launch the terminal, the following is in the path, so CMake works as expected.
I found two approaches for a quick fix. The first is to disable the plugin inside the plugin manager. The second is to disable it for the workspace. I also attempted to disable with the PlatformIO setting platformio-ide.activateOnlyOnPlatformIOProject however, this doesn't fix the issue. I am still trying to reason about how PlatformIO is doing environment variable injection. So far I have only come up with dead ends. I'll report back if I figure it out. |
We are also trying to figure out the same, but this could take a little time from our end. |
One of the reasons is that the PlatformIO extension modifies the whole We use a modified copy of the process.env in our custom tasks without altering the original process.env which should be a non-conflict solution. We need to figure what is the thing they are doing that is messing up the |
I've noticed that PlatformIO has removed their Thanks @ivankravets Closing this since it is fixed. |
I just tried with v2.2.0 of the PlatformIO extension and it seems like this indeed fixes the issue. |
Describe the bug
With the latest Visual Studio Code ESP-IDF extension installed, and PlatformIO installed, Visual Studio Code does not honor the path settings that the Visual Studio Code ESP-IDF extension attempts to set. Notably, the first error that pops up during a build is the following:
'cmake' is not recognized as an internal or external command, operable program or batch file.
To Reproduce
1.) Install Visual Studio Code.
2.) Install the ESP-IDF extension
3.) Install the PlatformIO extension
4.) Attempt to build with the ESP-IDF extension
(Note: the order of 2+3 doesn't matter)
Expected behavior
I'd expect that regardless of any other plugins, Visual Studio Code's ESP-IDF would build. However, I'm not sure if the behavior described in this bug report is due to an issue in PlatformIO, or due to an issue with the ESP-IDF extension.
Environment (please complete the following information):
Windows 7
VSCode 1.49.3
ESP-IDF Version 4.2-release
VSCode ESP-IDF Extension 0.5.1
PlatformIO IDE 2.1.0
Python Version 3.8.6
Logs
'cmake' is not recognized as an internal or external command, operable program or batch file. The terminal process "C:\Windows\system32\cmd.exe /d /c cmake -G Ninja .." failed to launch (exit code: 1).
Additional context
I executed within a shell the ESP-IDF\export.bat and launched Visual Studio Code from that path, it solved the issue since it started Visual Studio Code with the correct paths to the tools. This firmly places the issue with the environment variable settings.
The text was updated successfully, but these errors were encountered: