Error while building project - no such file or directory about vs-code-stm32-ide HOT 12 CLOSED

True, adding files/folder sources to workspace that contain spaces throws error on make command. GNU Make does not handle paths with spaces at all. Also, currently implemented makefile parser does not handle spaces.

So, life is better if you generally avoid spaces in paths. I will add this note to readme files.
Thank you and let me know if there are any other bugs, improvements or suggestions.

I mostly avoid spaces in any path, but since your tutorial video contained a lot of them, I guessed it was OK, also I think paths can have spaces if you enclose them in double quotes.
anyway great job, great documentation, I was looking for this for a long time, thanks a lot.

from vs-code-stm32-ide.

seems logical, to be more clear here is what I concluded from the tests.
windows builds either from cmd or powershell should be OK even with spaces.
windows builds with bash based terminals or possibly linux and Mac builds should be OK only if there is no space in the path

from vs-code-stm32-ide.

confirmed, removing all the spaces from all paths, resulted in a successful build

from vs-code-stm32-ide.

True, adding files/folder sources to workspace that contain spaces throws error on make command. GNU Make does not handle paths with spaces at all. Also, currently implemented makefile parser does not handle spaces.

So, life is better if you generally avoid spaces in paths. I will add this note to readme files.
Thank you and let me know if there are any other bugs, improvements or suggestions.

from vs-code-stm32-ide.

True, adding files/folder sources to workspace that contain spaces throws error on make command. GNU Make does not handle paths with spaces at all. Also, currently implemented makefile parser does not handle spaces.

So, life is better if you generally avoid spaces in paths. I will add this note to readme files.
Thank you and let me know if there are any other bugs, improvements or suggestions.

I read the readme,

Anyway, paths to GCC/GNU/OPENOCD executables CAN include spaces because they are not used in the same manner as workspace sources.

my project path didn't have any spaces, it was the executables path that caused the problem, you can see the exact error message in my first post.

from vs-code-stm32-ide.

Very strange. I am currently working with all, GCC, make, OpenOCD and other paths that include spaces:

> Executing task in folder firmware: & 'C:/Users/domen/AppData/Roaming/GNU MCU Eclipse/Build Tools/2.11-20180428-1604/bin/make.exe' 'GCC_PATH=C:/Users/domen/AppData/Roaming/GNU MCU Eclipse/ARM Embedded GCC/7.3.1-1.1-20180724-0637/bin' <

C:/Users/domen/AppData/Roaming/GNU MCU Eclipse/ARM Embedded GCC/7.3.1-1.1-20180724-0637/bin/arm-none-eabi-gcc -c -mcpu=cortex-m0 -mthumb   -DAVOID_EMPTY_DEFINE_FIELD_C ........ -MF"build/comm.d" -Wa,-a,-ad,-alms=build/comm.lst userSrc/comm.c -o build/comm.o

• Is it possible to share your .vscode folder?
• Are you sure you are using the latest version?
• Is your toolpath folder structure sas recommended on GNU ARM Eclipse webpage?

from vs-code-stm32-ide.

yeah, I saw that in your video and thats odd.
Here is the complete Project folder minus the Driver directory:
vsCodeTest.zip
I believe i am using the latest version of everything:
VSCode: v1.28.2
arm-none-eabi: 7 2018-q2-update
default vscode termial: PowerShell, although tested with MSYS bash with the same result

Is your toolpath folder structure sas recommended on GNU ARM Eclipse webpage?

No, Here are the current paths:

D:\GNU-Tools-Arm-Embedded\7-2018-q2-update\bin\executable
D:\STMicroelectronics\GNU-MCU-Eclipse\Build-Tools\2.11-20180428-1604\bin\executable
D:\STMicroelectronics\GNU-MCU-Eclipse\OpenOCD\0.10.0-10-20181020-0522\bin\executable

the previous path were the same as above but included some spacing instead of dashes

from vs-code-stm32-ide.

Can't reproduce.
I am successfully running workspace tasks with build tools on paths that contain spaces. Tested also on build tools at non-standard location - not as recommended on GNU ARM Eclipse page. You can see all paths of my existing workspace settings in uploaded example/.vscode/buildData.json.backup file.
Running on Win10, python 3.6 (32bit), latest VS Code.

Your setup seems OK (according to the buildData.json, tasks.json and other files inside .vscode folder. Anyway, I am still interested in failing configuration.

from vs-code-stm32-ide.

If you have a specific set of configurations in mind, tell me to try to reproduce the error with that.
my guess was that you needed additional quotes for passing

 "GCC_PATH=D:/GNU-Tools-Arm-Embedded/7-2018-q2-update/bin"

to the Build Project task. like this:

 "GCC_PATH=\"D:/GNU-Tools-Arm-Embedded/7-2018-q2-update/bin\""

from vs-code-stm32-ide.

Well, the best you can do is to reproduce the error and send me exact copy of complete workspace. Usually quoting paths on windows solve problems with spaces, but since VS Code task arguments are automatically quoted with ', so additional ' or " quotes again introduce issues.

I've had a hard time finding the right way to generate CPU: Download and run task, where "program build/something.elf verify reset exit" argument includes path. The only working solution I found was to set a relative path, wich is always without spaces (generated by make command).

Bottom line, I won't change&commit anything untill I can't reproduce exact error.

from vs-code-stm32-ide.

well I tried to reproduce the error in power shell with no luck, note the space in GNU Tools-Arm-Embedded path

D:/STMicroelectronics/GNU-MCU-Eclipse/Build-Tools/2.11-20180428-1604/bin/make.exe 'GCC_PATH=D:/GNU Tools-Arm-Embedded/7-2018-q2-update/bin'
D:/GNU Tools-Arm-Embedded/7-2018-q2-update/bin/arm-none-eabi-gcc -c -mcpu=cortex-m4 -mthumb -mfpu=fpv4-sp-d16 -mfloat-abi=hard -DAVOID_EMPTY_DEFINE_FIELD_C -DUSE_HAL_DRIVER -DSTM32F446xx -IInc -IDrivers/STM32F4xx_HAL_Driver/Inc -IDrivers/STM32F4xx_HAL_Driver/Inc/Legacy -IDrivers/CMSIS/Device/ST/STM32F4xx/Include -IDrivers/CMSIS/Include -Og -Wall -fdata-sections -ffunction-sections -g -gdwarf-2 -MMD -MP -MF"build/main.d" -Wa,-a,-ad,-alms=build/main.lst Src/main.c -o build/main.o
D:/GNU Tools-Arm-Embedded/7-2018-q2-update/bin/arm-none-eabi-gcc build/main.o build/stm32f4xx_it.o build/stm32f4xx_hal_msp.o build/stm32f4xx_hal_tim.o build/stm32f4xx_hal_tim_ex.o build/stm32f4xx_hal_uart.o build/stm32f4xx_hal_rcc.o build/stm32f4xx_hal_rcc_ex.o build/stm32f4xx_hal_flash.o build/stm32f4xx_hal_flash_ex.o build/stm32f4xx_hal_flash_ramfunc.o build/stm32f4xx_hal_gpio.o build/stm32f4xx_hal_dma_ex.o build/stm32f4xx_hal_dma.o build/stm32f4xx_hal_pwr.o build/stm32f4xx_hal_pwr_ex.o build/stm32f4xx_hal_cortex.o build/stm32f4xx_hal.o build/system_stm32f4xx.o build/startup_stm32f446xx.o -mcpu=cortex-m4 -mthumb -mfpu=fpv4-sp-d16 -mfloat-abi=hard -specs=nano.specs -TSTM32F446RETx_FLASH.ld  -lc -lm -lnosys -Wl,-Map=build/vsCodeTest.map,--cref -Wl,--gc-sections -o build/vsCodeTest.elf
D:/GNU Tools-Arm-Embedded/7-2018-q2-update/bin/arm-none-eabi-size build/vsCodeTest.elf
   text    data     bss     dec     hex filename
   5868      20    1636    7524    1d64 build/vsCodeTest.elf
D:/GNU Tools-Arm-Embedded/7-2018-q2-update/bin/arm-none-eabi-objcopy -O ihex build/vsCodeTest.elf build/vsCodeTest.hex
D:/GNU Tools-Arm-Embedded/7-2018-q2-update/bin/arm-none-eabi-objcopy -O binary -S build/vsCodeTest.elf build/vsCodeTest.bin

then I switched back to MSYS bash and tada, here the error appears again

$ D:/STMicroelectronics/GNU-MCU-Eclipse/Build-Tools/2.11-20180428-1604/bin/make.exe 'GCC_PATH=D:/GNU Tools-Arm-Embedded/7-2018-q2-update/bin'
D:/GNU Tools-Arm-Embedded/7-2018-q2-update/bin/arm-none-eabi-gcc -c -mcpu=cortex-m4 -mthumb -mfpu=fpv4-sp-d16 -mfloat-abi=hard -DAVOID_EMPTY_DEFINE_FIELD_C -DUSE_HAL_DRIVER -DSTM32F446xx -IInc -IDrivers/STM32F4xx_HAL_Driver/Inc -IDrivers/STM32F4xx_HAL_Driver/Inc/Legacy -IDrivers/CMSIS/Device/ST/STM32F4xx/Include -IDrivers/CMSIS/Include -Og -Wall -fdata-sections -ffunction-sections -g -gdwarf-2 -MMD -MP -MF"build/main.d" -Wa,-a,-ad,-alms=build/main.lst Src/main.c -o build/main.o
/usr/bin/sh: D:/GNU: No such file or directory
make: *** [Makefile:156: build/main.o] Error 127

so it seems that MSYS bash or possibly linux bash have problems with spaces in arguments, and adding single or double quotes also wont help. the only thing I could do to fix the problem was replacing all the spaces with \space, which results in successful build:

 D:/STMicroelectronics/GNU-MCU-Eclipse/Build-Tools/2.11-20180428-1604/bin/make.exe 'GCC_PATH=D:/GNU\ Tools-Arm-Embedded/7-2018-q2-update/bin'
D:/GNU\ Tools-Arm-Embedded/7-2018-q2-update/bin/arm-none-eabi-gcc -c -mcpu=cortex-m4 -mthumb -mfpu=fpv4-sp-d16 -mfloat-abi=hard -DAVOID_EMPTY_DEFINE_FIELD_C -DUSE_HAL_DRIVER -DSTM32F446xx -IInc -IDrivers/STM32F4xx_HAL_Driver/Inc -IDrivers/STM32F4xx_HAL_Driver/Inc/Legacy -IDrivers/CMSIS/Device/ST/STM32F4xx/Include -IDrivers/CMSIS/Include -Og -Wall -fdata-sections -ffunction-sections -g -gdwarf-2 -MMD -MP -MF"build/main.d" -Wa,-a,-ad,-alms=build/main.lst Src/main.c -o build/main.o
D:/GNU\ Tools-Arm-Embedded/7-2018-q2-update/bin/arm-none-eabi-gcc build/main.o build/stm32f4xx_it.o build/stm32f4xx_hal_msp.o build/stm32f4xx_hal_tim.o build/stm32f4xx_hal_tim_ex.o build/stm32f4xx_hal_uart.o build/stm32f4xx_hal_rcc.o build/stm32f4xx_hal_rcc_ex.o build/stm32f4xx_hal_flash.o build/stm32f4xx_hal_flash_ex.o build/stm32f4xx_hal_flash_ramfunc.o build/stm32f4xx_hal_gpio.o build/stm32f4xx_hal_dma_ex.o build/stm32f4xx_hal_dma.o build/stm32f4xx_hal_pwr.o build/stm32f4xx_hal_pwr_ex.o build/stm32f4xx_hal_cortex.o build/stm32f4xx_hal.o build/system_stm32f4xx.o build/startup_stm32f446xx.o -mcpu=cortex-m4 -mthumb -mfpu=fpv4-sp-d16 -mfloat-abi=hard -specs=nano.specs -TSTM32F446RETx_FLASH.ld  -lc -lm -lnosys -Wl,-Map=build/vsCodeTest.map,--cref -Wl,--gc-sections -o build/vsCodeTest.elf
D:/GNU\ Tools-Arm-Embedded/7-2018-q2-update/bin/arm-none-eabi-size build/vsCodeTest.elf
   text    data     bss     dec     hex filename
   5868      20    1636    7524    1d64 build/vsCodeTest.elf
D:/GNU\ Tools-Arm-Embedded/7-2018-q2-update/bin/arm-none-eabi-objcopy -O ihex build/vsCodeTest.elf build/vsCodeTest.hex
D:/GNU\ Tools-Arm-Embedded/7-2018-q2-update/bin/arm-none-eabi-objcopy -O binary -S build/vsCodeTest.elf build/vsCodeTest.bin

from vs-code-stm32-ide.

I see. Well, in that case, I will leave the current configuration as it is. It is much more readable (than escaping), convenient and system versatile to just avoid spaces and use the default VS Code integrated terminal, which is cmd.exe.

Updated FAQ.

from vs-code-stm32-ide.