Skip to content
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

Closed
hustlelabs opened this issue Oct 4, 2020 · 8 comments · Fixed by #196
Closed

[Bug Report]: Conflict with PlatformIO and ESP-IDF Extension (VSC-456) #190

hustlelabs opened this issue Oct 4, 2020 · 8 comments · Fixed by #196
Assignees
Labels
bug Its an actual bug as determined by the maintainers

Comments

@hustlelabs
Copy link

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.

@hustlelabs hustlelabs added the bug-report Bug Report from users on Github (don't use this tag manually, its supposed to be used via the issue) label Oct 4, 2020
@github-actions github-actions bot changed the title [Bug Report]: [Bug Report]: (VSC-456) Oct 4, 2020
@pwmb pwmb changed the title [Bug Report]: (VSC-456) [Bug Report]: Conflict with PlatformIO and ESP-IDF Extension (VSC-456) Oct 5, 2020
@pwmb pwmb self-assigned this Oct 5, 2020
@pwmb pwmb added the Configuration Related This is related to the misconfiguration of the extension settings or improper path has been set label Oct 5, 2020
@pwmb
Copy link
Contributor

pwmb commented Oct 5, 2020

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:

2.) Install the ESP-IDF extension

Did you try to run the Onboarding after you install the extension, because then it should have set the idf.customExtraPaths?

Also we have added IDF Terminal into the extension which will also open a terminal by exposing all the IDF related PATHS into the terminal as well.

@hustlelabs
Copy link
Author

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.

@pwmb
Copy link
Contributor

pwmb commented Oct 5, 2020

... and what about when you run the IDF Terminal command by pressing F1 or CtrlE + T, and type cmake there, does that also give you error?

'cmake' is not recognized as an internal or external command, operable program or batch file.

In the meantime we are testing with installing the ESP32 platform on PlatformIO for Windows

Update:

@hustlelabs We able to replicate the issues, will fix the same ASAP. Thanks for the bug report!

Update 2:

@hustlelabs For quick unblocking of this issue if possible please uninstall the platformio extension, since due to conflicting paths/configs injecting into the process.env is causing the error.

We will investigate this issue further and keep you posted

@pwmb pwmb added bug Its an actual bug as determined by the maintainers and removed Configuration Related This is related to the misconfiguration of the extension settings or improper path has been set bug-report Bug Report from users on Github (don't use this tag manually, its supposed to be used via the issue) labels Oct 5, 2020
@hustlelabs
Copy link
Author

When I launch the terminal, the following is in the path, so CMake works as expected.

C:\Users\[USER]\.espressif\python_env\idf4.2_py3.8_env\Scripts;C:\Users\[USER]\esp-idf\components\esptool_py\esptool;C:\Users\[USER]\esp-idf\components\espcoredump;C:\Users\[USER]\esp-idf\components\partition_table;C:\Users\[USER]\.espressif\python_env\idf4.2_py3.8_env\Scripts;c:\python38;C:\Users\[USER]\.espressif\tools\xtensa-esp32-elf\esp-2020r2-8.2.0\xtensa-esp32-elf\bin;C:\Users\[USER]\.espressif\tools\xtensa-esp32s2-elf\esp-2020r2-8.2.0\xtensa-esp32s2-elf\bin;C:\Users\[USER]\.espressif\tools\esp32ulp-elf\2.28.51-esp-20191205\esp32ulp-elf-binutils\bin;C:\Users\[USER]\.espressif\tools\esp32s2ulp-elf\2.28.51-esp-20191205\esp32s2ulp-elf-binutils\bin;C:\Users\[USER]\.espressif\tools\cmake\3.16.4\bin;C:\Users\[USER]\.espressif\tools\openocd-esp32\v0.10.0-esp32-20200420\openocd-esp32\bin;C:\Users\[USER]\.espressif\tools\ninja\1.10.0;C:\Users\[USER]\.espressif\tools\idf-exe\1.0.1;C:\Users\[USER]\.espressif\tools\ccache\3.7;C:\Users\[USER]\.espressif\tools\dfu-util\0.9\dfu-util-0.9-win64;C:\Users\[USER]\.espressif\python_env\idf4.2_py3.8_env;C:\Users\[USER]\esp-idf\tools;C:\Users\[USER]\.platformio\penv\Scripts;C:\Users\[USER]\.platformio\penv;C:\Users\[USER]\.platformio\python3

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.

@pwmb
Copy link
Contributor

pwmb commented Oct 5, 2020

We are also trying to figure out the same, but this could take a little time from our end.

@brianignacio5
Copy link
Collaborator

brianignacio5 commented Oct 10, 2020

One of the reasons is that the PlatformIO extension modifies the whole process.env which makes other extensions susceptible to whatever they modify as shown in their code in https://github.com/platformio/platformio-vscode-ide/blob/355f48db2119e612edc6adb2dfa0c70f824832f2/src/terminal.js#L12 and PlatformIO-node-helpers https://github.com/platformio/platformio-node-helpers/blob/master/src/proc.js .

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 Path env variable.

@brianignacio5
Copy link
Collaborator

I've noticed that PlatformIO has removed their process.env changes and they use their own env variable now as shown in platformio/platformio-node-helpers@3a149e4

Thanks @ivankravets

Closing this since it is fixed.

@brianignacio5 brianignacio5 unpinned this issue Nov 3, 2020
@ghost
Copy link

ghost commented Nov 7, 2020

I just tried with v2.2.0 of the PlatformIO extension and it seems like this indeed fixes the issue.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Its an actual bug as determined by the maintainers
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants