Adding C:\Users\N\.particle\toolchains\buildtools\1.1.1\bin to the Windows PATH environment variable solved the problem.
Seems like the bash called for compilation uses the Windows PATH and the folder got removed somehow and not re-added.
Adding C:\Users\N\.particle\toolchains\buildtools\1.1.1\bin to the Windows PATH environment variable solved the problem.
you shouldn't ever need to mess with your PATH. try the following:
run the Particle: Launch Compiler Shell command
in the terminal instance that launches, run env
look for the PATH line in the data returned by env
you should see a string that starts with entries that look like:
PATH=/cygdrive/c/Users/me/.vscode/extensions/particle.particle-vscode-core-1.12.2/src/cli/bin/windows/amd64:/cygdrive/c/Users/me/.particle/toolchains/gcc-arm/9.2.1/bin:/usr/bin:/cygdrive/c/Users/me/.particle/toolchains/openocd/0.11.2-adhoc6ea4372.0/bin:<more records here>
in that same terminal window, run: which make
you should get back:
/usr/bin/make
likewise, running which bash should give you /usr/bin/bash
After updating Windows to 2004
that could be the issue - run the Particle: Audit Environment command and share the platform and workspace fields. here are the important platform values as reported by my test machine:
I have a similar, possibly related issue. No external dependencies, have been building for months - suddenly, everything is broken. When attempting a local compile:
':::: COMPILING APPLICATION
'DEVICE' is not recognized as an internal or external command,
operable program or batch file.
make: *** [compile-all] Error 1
The terminal process "C:\Users\Anthony\.particle\toolchains\buildtools\1.1.1\bin\bash.exe '-c', 'make -f 'C:\Users\Anthony\.particle\toolchains\buildscripts\1.9.2\Makefile' compile-all -s'" failed to launch (exit code: 2).
It’s also complained about not finding crc32 in other contexts.
Everything points to an issue with the PATH / environment not getting set correctly when using the makefile. In response to @m_m’s recommendations:
Running env in the “Compiler Shell” context just shows my normal Windows PATH, no cygdrive paths appended.
Running which make shows another GnuWin32 make I have on my usual PATH, not the cygwin make.
I did update to Windows 2004 about a month ago, but was successfully building for a couple weeks after that - so I’m hesitant to say this is related.
My platform information from the Audit Environment command are the same as @m_m’s above:
Adding the Particle buildtools to my Windows PATH as @nils suggests temporarily resolves the issue, but isn’t a real solution - why is the Particle Makefile suddenly unable to properly set up its environment?
Thank you @m_m for the assistance. I removed the manually added path entry and tried what you suggested:
bash-4.4$ env
bash: env: Kommando nicht gefunden.
bash-4.4$ which make
bash: which: Kommando nicht gefunden.
bash-4.4$ which bash
bash: which: Kommando nicht gefunden.
Looking at PATH with echo $PATH, the only entry belonging to Particle is
/cygdrive/c/Users/N/AppData/Local/particle/bin
Audit Environment (some unimportant fields replaced by …):
My PATH has 40 entries, all starting with /cygdrive/c/.... But the only one containing “particle” is /cygdrive/c/Users/N/AppData/Local/particle/bin.
that could be the issue - windows places a limit on the total number of characters (iirc 4095). can you try removing as many of the entries as you can, rebooting, and trying again?
couldn't hurt to update VSCode (current version as of today is v1.49.0). if you have a "stock" windows install around that you can install Particle Workbench on and then compare between installs, that'd probably help shed some light on things as well. beyond that, i'm stumped.
My PATH variable (in the compiler shell shown by echo $PATH or set) has a total length of 3305 characters. It contains 77 entries, of which 40 are unique (this was the number I mentioned). 37 entries are duplicates.
The PATH in the Windows environment variables settings has only 5 entries, which are part of the 40 entries in the compiler shell path. This is where I added C:\Users\N\.particle\toolchains\buildtools\1.1.1\bin to fix this issue.
Updating VSCode to 1.49.0 did not help. I don’t have another Windows machine here for comparing.
As VSCode with the Particle extensions are working on other Windows 10 2004 machines, this seems to be an individual problem with my installation. I think I have to reinstall VSCode, Particle drivers or ultimately windows.
But as the workaround with the addition to the Windows path is working fine and permanently across reboots, I think this is a valid solution for now.
I added C:\Users\N\.particle\toolchains\buildtools\1.1.1\bin to fix this issue.
while this might unblock you short-term, it's not a long-term solution as we update the dependency from time to time (iow, the 1.1.1 (version) part of the path will change in the future).
I think I have to reinstall VSCode, Particle drivers or ultimately windows.
just to save you some effort, reinstalling - especially windows itself - will almost certainly not help.
i'm curious if you were running cygwin (or had it installed) prior to using Workbench?
under the hood, Workbench uses VSCode's extension APIs (docs: 1, 2, 3) to spawn a terminal instance using cygwin's bash with a number of environment variables (PATH, PARTICLE_MAKEFILE, etc) preconfigured based on your project's configuration. it's basically:
i'm not sure what would cause the behavior you are seeing where apparently PATH (and perhaps other environment variables) are not being set properly. i might open an issue over in the VSCode repo to see if they have any ideas - GitHub - microsoft/vscode: Visual Studio Code
either way, thanks for the report and apologies for the bumps
I understand, so I will continue using the old path after an update, or it stops working again if the old path is removed.
Ok, but don't you think there is a conflict with something that happened specifically on my machine at some point in the past?
I am not sure about this. I used cygwin a very long time ago, but I can not remember if it was my current (using since 2 years) or the last machine. But I can say for sure that I did not use cygwin ever since Particle Workbench has been released. cygwin is installed on my machine right now (startmenu entry).
Thank you again for the help! If you want to continue searching for the issue, I will provide the information you need, but I think I have to too little knowledge about the build plugins to open an issue at VSCode myself.
don’t you think there is a conflict with something that happened specifically on my machine at some point in the past?
yes, but it's sort of overkill in that the issue almost certainly comes down to a weird configuration or conflicting software like...
cygwin is installed on my machine right now (startmenu entry).
Workbench doesn't actually run the cygwin installer - it just drops the required subset of tools into the ~\.particle\toolchains\buildtools directory and references them as needed.
Maybe try running the uninstaller for cygwin (should be in that start menu entry somewhere) and see if things improve.
If you want to continue searching for the issue, I will provide the information you need,
thank you
but I think I have to too little knowledge about the build plugins to open an issue at VSCode myself.
There is no uninstall entry
and in "Apps & Features" in the system settings there is also no entry for cygwin, thus I can't uninstall it. cygwin is located in C:\cygwin64
Setting my Windows PATH to include
C:\Users\ianda.particle\toolchains\buildtools\1.1.1\bin worked for me too as I simply do not have the time to investigate any further and have code to issue.
Perhaps the onus should be on Particle devs to investigate why their tools break?
update: thanks to @nils for helping me troubleshoot, we were able to confirm that the issue is being caused by a conflict between the PlatformIO extension and Workbench. it seems they released an update recently (September 10th) that likely introduced this issue. from what i’ve heard, prior versions worked fine alongside Particle Workbench.
short-term, the fix is to disable the PlatformIO extension and close + reopen VSCode.
i’ll try to diagnose the underlying problem and work with the PlatformIO and VSCode teams to get some sort of fix in place.