add vs code launch.json auto generation in waf configure

[Huibean]

auto generate vscode launch.json for setup stm32 gdb or SITL lldb debug session in VSCODE
waf configure arg "--vs-launch", only active --debug
example command
./waf configure --board Pixhawk4 --debug --vs-launch
STM32 debug need https://github.com/Marus/cortex-debug and STLINK

./waf configure --board sitl --debug --vs-launch

[joshanne]

I don't think this is right - pointing to the stlink-v2 config.

The most of the stlink*.cfg files point to the more common stlink.cfg - eg: https://github.com/openocd-org/openocd/blob/master/tcl/interface/stlink-v2.cfg

[Huibean]

You are right, thanks for the hint, shoule be stlink.cfg, updated

[joshanne]

I don't know that this is a valid model for all vehicle types/targets

[Huibean]

Should accept a extra params to overwirite this, now it's more like a template, the default params I get from the output of sim_vehicle.py

[joshanne]

https://github.com/ArduPilot/ardupilot/blob/master/Tools/debug/openocd-h7.cfg

The ardupilot supplied openocd H7 config file points to dual bank.

Not sure if we should also point this to stm32h7x_dual_bank.cfg.

When I've debugged on hardware, I have used the ardupilot config file to talk to the H7.

[Huibean]

should include the dualbank, I am trying to find the dual bank condition in waf env

[MichelleRos]

Good idea to have launch.json in the code itself rather than making people copy it from the documentation, but I'm wondering whether it wouldn't be simpler to commit a launch.default.json file to the repo? (Like how we have a settings.default.json)

Also, I tested the PR and it generated the launch.json file but when I tried to then launch it, I got this error message:

I'm not sure why it is giving me this error, since I've been using vscode with gdb with my previous launch.json file without issues.

[Huibean]

Good idea to have launch.json in the code itself rather than making people copy it from the documentation, but I'm wondering whether it wouldn't be simpler to commit a launch.default.json file to the repo? (Like how we have a settings.default.json)

Also, I tested the PR and it generated the launch.json file (or, overwrote the one I had which has been working correctly) but when I tried to then launch it, I got this error message:

for SITL using a launch.default.json seems fine, when switching different board tagerts launch.json would be hard to maintain unless adding board var to settings.json and using the var in launch.json,this could avoid the option list being so long to cover all case, would you mind upload your generated launch.json?

[Huibean]

the above error should coming from using lldb in WSL(linux), code updated, use gdb instead outside macos

[Huibean]

2024.12.16 update
thanks @robertlong13 and @rmackay9 sharing launch.json snippets

1. allow H7 use dual_back cfg in openocd
2. add allow using launch_profile.json to store perference configs(items in launch_profile.json will overwrite the launch.json)
   cp .vscode/launch_profile.default.json .vscode/launch_profile.json

what's the benefit of using --vs-launch instead of copy template launch.json from document?

1. fast generating a working launch.json for new users
2. quick handling build path with board target changes
3. flexible perference by using launch_profile.json

[robertlong13]

Overall, I like the idea, but I think we need to find a way to make it generate on build instead of on configure. That way, we don't need a launch configuration for every vehicle binary, just one for the last one configured/built. The --vs-launch option should just create/overwrite one launch configuration named "vs-launch" with whatever the last build was. I poked around trying to see if I could get that to work, but I've run out of time, and I don't know waf well enough yet.

I also don't think we should automatically delete the launch.json on a parse error. Throw an error and quit. Make the user fix it or delete it themselves. Since launch.json is gitignored, if we delete it, you'll likely be losing something that isn't backed up anywhere.

[robertlong13]

Need to use something that supports comments. Something like this: https://github.com/Kijewski/pyjson5

Otherwise, you will pretty much always get a parse failure and will delete the user's existing launch.json.

[robertlong13]

Suggested change

	merge_dicts(launch_configuration, launch_profile.get('sitl'))
	launch_configuration |= launch_profile.get('sitl')

Don't need to implement a dictionary merger. This is supported in 3.9+ https://peps.python.org/pep-0584/

[Huibean]

thanks

[Huibean]

Overall, I like the idea, but I think we need to find a way to make it generate on build instead of on configure. That way, we don't need a launch configuration for every vehicle binary, just one for the last one configured/built. The --vs-launch option should just create/overwrite one launch configuration named "vs-launch" with whatever the last build was. I poked around trying to see if I could get that to work, but I've run out of time, and I don't know waf well enough yet.

I also don't think we should automatically delete the launch.json on a parse error. Throw an error and quit. Make the user fix it or delete it themselves. Since launch.json is gitignored, if we delete it, you'll likely be losing something that isn't backed up anywhere.

my first try is putting it in the waf build, then I thought about not to slow down the build process, I will update it raise a error instead of delete a launch.json with syntax error