This repository was archived by the owner on Oct 1, 2024. It is now read-only.
Why can't arduino.json "output" share the same output folder that is generated for debugging?
#1473
Labels
fixed-pending-release
Fix is merged and will be included in the next release.
Comments
zfields
changed the title
arduino.json "output" be the same as the output folder generated for debugging?arduino.json "output" share the same output folder that is generated for debugging?
|
@zfields Could you share your test project including your debug configuration (launch.json if you have one) so that I can attempt to repro? Thanks! |
gcampbell-msft
added
needs-more-info
|
What board do you have? I'll try and tailor a project just for you. IIRC, you can just use the extension to create the blink sketch, and try and debug it and it will cause the issue to repro when it generates the build. No board required. |
|
I'm using one of the STM Discovery Boards, STMicroelectronics B-L4S5I-IOTOA1. My main question is what your debugging configuration looks like. |
|
For the most part, it's the one that gets generated by the extension. I'm using OpenOCD as well. Here are the full instructions. {
// Use IntelliSense to learn about possible attributes.
// Hover to view descriptions of existing attributes.
// For more information, visit: https://go.microsoft.com/fwlink/?linkid=830387
"version": "0.2.0",
"configurations": [
{
"name": "Arduino",
"type": "arduino",
"request": "launch",
"program": "${file}",
"cwd": "${workspaceFolder}",
"MIMode": "gdb",
"targetArchitecture": "arm",
"miDebuggerPath": "",
"debugServerPath": "/usr/bin/openocd",
"debugServerArgs": "-f interface/stlink.cfg -f target/stm32l4x.cfg",
"customLaunchSetupCommands": [
{
"text": "target remote localhost:3333"
},
{
"text": "file \"${file}\""
},
{
"text": "load"
},
{
"text": "monitor reset halt"
},
{
"text": "monitor reset init"
}
],
"stopAtEntry": true,
"serverStarted": "Info\\ :\\ [\\w\\d\\.]*:\\ hardware",
"launchCompleteCommand": "exec-continue",
"filterStderr": true,
"args": []
}
]
} |
|
Great. I'll attempt to repro as soon as my bandwidth allows and try to make sure this is reproducible. I should also mention that the experience you're describing is very likely by design (I'll look into this along with attempting to reproduce), as build files often get overwritten and its often better practice to keep them separate. |
gcampbell-msft
added
investigating
and removed
needs-more-info
|
Kinda, sorta... I don't think it should arbitrarily choose a directory, it should probably throw an error and/or warning. I would prefer to be able to specify this decision in a parameter instead of it being decided for me. |
|
@zfields What version of the extension do you have installed? I'm able to repro the first scenario you mentioned |
In building the table above, I fully understand the behavior, and there are two issues.
ERROR |
|
@zfields Understood. What version of the extension are you running? I can confirm that I'm reproducing all of the scenarios you laid out except for the first where it creates a /tmp folder and I don't see anywhere in the code that creates a folder like that. I've published a PR that attempts to fix most of these issues (the ones listed in 1 and 2). If you download the VSIX from this PR and test with it, could you confirm that it solves your issues? Here is the link where the VSIX's are located. |
|
Ahhh... I'm on a Linux machine. To recount, if I don't specify an and I will eventually see this from the compiler output... Check the end of the 5th line from the bottom: You can see the output goes into Thanks for all the help! I will test your .vsix and get back to you. |
|
I love it, it works perfectly! The only other thing I would like to see change, is to add ... "output": ".build"... to the You have already chosen it as the path for the debug binaries, and this would shine light on where someone might expect to find them. Also, I don't understand the value of not caching the build output (e.g. using |
|
Reopening because the fix is merged but not yet released. |
benmcmorran
added
fixed-pending-release
|
This issue has been fixed in the latest release of this extension, which is available in the VS Code extension marketplace. |
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
I LOVE the debugging feature of VSCode for Arduino!
When I debug, instead of using a
/tmpfolder, it automatically creates the folder${workspaceRoot}/.build/BluesW- I love it.What I don't love, is that I can't use that same folder for the
outputkey in myarduino.json. If I specify.build/BluesWto match the folder that has already been created, then it will put the binaries in.build/BluesW/BluesW. However, when I simply specify.buildit will place the binaries in the root of the.buildfolder (as you would expect). 🤷Also, if I completely remove the
.buildfolder, but I have a nested path (e.g..build/BluesW) specified foroutput, then it throws an error that the directory does not exist.Here is my
arduino.jsonfile:arduino.json{
"configuration": "pnum=SWAN_R5,upload_method=swdMethod,xserial=generic,usb=CDCgen,xusb=FS,opt=ogstd,dbg=enable,rtlib=nano",
"board": "STMicroelectronics:stm32:BluesW",
"port": "/dev/ttyACM0",
"sketch": "gh-issue-1473.ino",
"output":".build/BluesW/"
}
The text was updated successfully, but these errors were encountered: