clean command fails in windows

[jantje]

reported in #1359 and regression due to fix of #1210

Basically #1210 introduced a sh in the toolchain and therefore the del command is no longer recognized when running make (because sh does not know del and cmd does)

[jantje]

Strange ... in my other test environment I could not reproduce the issue and del worked fine. I assume it depends on the content in the make folder.
Sloeber currently uses this make.zip file https://github.com/Sloeber/arduino-eclipse-plugin/files/2695478/make.zip
Even though this zip works with del; rm is a better option as no special code is needed.

[jantje]

Note that to upgrade the make folder Sloeber checks for the existence of make.exe and sh.exe.
The new zip contains way more commands. So force a upgrade; stop Sloeber; delete the arduinoplugin/tools/make folder; start Sloeber

[PerennialNovice]

hmm, I was not able to upgrade the make folder by using the above described method.
Is that related to me using the 4.3.3 product and not the current nightly build?

[jantje]

In 4.3.3 Sloeber will uise the old make.zip
So in your case you should rename the make folder (like make V4.3.3 and unzip the above make.zip so there is again a make folder that contains make.exe

[PerennialNovice]

that's what I did after the upgrade did not change anything
build -clean still fails

[jantje]

that's what I did after the upgrade did not change anything
build -clean still fails

Strange; This with the default path?

[PerennialNovice]

no, sloeber_path_extension is set to c:\git\bin
with that undefined, all is well
I think this is strongly related to the path issue in #1359

[jantje]

I think this is strongly related to the path issue in #1359

sure it is.

[PerennialNovice]

Is there anything I can do to help track down this problem?

[jantje]

You could try wether rm works fin on your system
To do so. Make a project, build it, goto project properties->C/C++ disable the automatic makefile generation
Select apply/ok
Got to project/release open the makefile and search for del. It shoule be something like
RM=del
replace del with rm
save (ignore warning)
run clean

[PerennialNovice]

For some reason, now I am not able to build anymore after clean (before changing from del to rm)

"C:\Sloeber\arduinoPlugin\packages\arduino\tools\avr-gcc\7.3.0-atmel3.6.1-arduino7/bin/avr-gcc-ar" rcs     C:\Users\ansay\Documents\sloeber-workspace\test\Release/arduino.ar  .\core\core\CDC.cpp.o .\core\core\HardwareSerial.cpp.o .\core\core\HardwareSerial0.cpp.o .\core\core\HardwareSerial1.cpp.o .\core\core\HardwareSerial2.cpp.o .\core\core\HardwareSerial3.cpp.o .\core\core\IPAddress.cpp.o .\core\core\PluggableUSB.cpp.o .\core\core\Print.cpp.o .\core\core\Stream.cpp.o .\core\core\Tone.cpp.o .\core\core\USBCore.cpp.o .\core\core\WInterrupts.c.o .\core\core\WMath.cpp.o .\core\core\WString.cpp.o .\core\core\abi.cpp.o .\core\core\hooks.c.o .\core\core\main.cpp.o .\core\core\new.cpp.o .\core\core\wiring.c.o .\core\core\wiring_analog.c.o .\core\core\wiring_digital.c.o .\core\core\wiring_pulse.S.o .\core\core\wiring_pulse.c.o .\core\core\wiring_shift.c.o 
c:\sloeber\arduinoplugin\packages\arduino\tools\avr-gcc\7.3.0-atmel3.6.1-arduino7\bin\../lib/gcc/avr/7.3.0/../../../../avr/bin/ar.exe: C:UsersansayDocumentssloeber-workspacetestRelease/arduino.ar: No such file or directory
make[1]: *** [makefile:84: C:\Users\ansay\Documents\sloeber-workspace\test\Release\arduino.ar] Error 1
make: *** [makefile:69: all] Error 2
"C:/Sloeber/arduinoPlugin/tools/make/make -j8 all" terminated with exit code 2. Build might be incomplete.```

again, undefining sloeber_path_extension temporarily fixed this:
I could build and clean without error

when I redefine sloeber_path_extension clean incremental build work fine, but a fresh build after clean fails with the above error message

It is but a wild guess, but might a Windows update have interferred (I updated a lot today...)

[jantje]

I know the whole set-up is very path/tool sensitive on windows. That is why I decided to force a "standard newly installed windows path" in Sloeber. (and work with FQN)
Changing the default Sloeber path is therefore very likely to lead to a rabit hole. Especially when there are linux like tools in the added paths.
If it works with the Sloeber default path and it doesn't with a non-standard path; the Sloeber position is "You have a path issue on your system, not a Sloeber issue"

Now I think of it. For your issue (calling a command that needs a different path). The best solution is probably to make a script file (like bat file) and set the path in there before calling your code. Adding a folder only containing that script file to Sloeber should be safe

[PerennialNovice]

Brilliant idea!
I'll give it a try as soon as I have a few spare moments

[PerennialNovice]

Yep, this worked!
Although I had to reset the PATH to its initial value within the .bat file...

clean, initial build and incremental build, all work now

me happy :)

Thank you so much for this nice workaround 👍

[jantje]

Although I had to reset the PATH to its initial value within the .bat file...

That is as expected because sloeber changes the path before starting the makefile.

clean, initial build and incremental build, all work now

Cool