Re: [RFC PATCH v2 1/1] devtools: add vscode configuration generator

[Bruce Richardson <bruce.richardson@intel.com>]

On Mon, Jul 29, 2024 at 02:05:52PM +0100, Anatoly Burakov wrote:
> A lot of developers use Visual Studio Code as their primary IDE. This
> script generates a configuration file for VSCode that sets up basic build
> tasks, launch tasks, as well as C/C++ code analysis settings that will
> take into account compile_commands.json that is automatically generated
> by meson.
> 
> Files generated by script:
>  - .vscode/settings.json: stores variables needed by other files
>  - .vscode/tasks.json: defines build tasks
>  - .vscode/launch.json: defines launch tasks
>  - .vscode/c_cpp_properties.json: defines code analysis settings
> 
> The script uses a combination of globbing and meson file parsing to
> discover available apps, examples, and drivers, and generates a
> project-wide settings file, so that the user can later switch between
> debug/release/etc. configurations while keeping their desired apps,
> examples, and drivers, built by meson, and ensuring launch configurations
> still work correctly whatever the configuration selected.
> 
> This script uses whiptail as TUI, which is expected to be universally
> available as it is shipped by default on most major distributions.
> However, the script is also designed to be scriptable and can be run
> without user interaction, and have its configuration supplied from
> command-line arguments.
> 
> Signed-off-by: Anatoly Burakov <anatoly.burakov@intel.com>
> ---
> 
Just was trying this out, nice script, thanks.

Initial thoughts concerning the build directory:
- the script doesn't actually create the build directory, so there is no
  guarantee that the build directory created will have the same parameters
  as that specified in the script run. I'd suggest in the case where the
  user runs the script and specifies build settings, that the build
  directory is then configured using those settings.

- On the other hand, when the build directory already exists - I think the
  script should pull all settings from there, rather than prompting the
  user.

- I'm not sure I like the idea for reconfiguring of just removing the build
  directory and doing a whole meson setup command all over again. This
  seems excessive and also removes the possibility of the user having made
  changes in config to the build dir without re-running the whole config
  script. For example, having tweaked the LTO setting, or the
  instruction_set_isa_setting. Rather than deleting it and running meson
  setup, it would be better to use "meson configure" to adjust the one
  required setting and let ninja figure out how to propagate that change.
  That saves the script from having to track all meson parameters itself.

- Finally, and semi-related, this script assumes that the user does
  everything in a single build directory. Just something to consider, but
  my own workflow till now has tended to keep multiple build directories
  around, generally a "build" directory, which is either release or
  debugoptimized type, and a separate "build-debug" directory + occasionally
  others for build testing. When doing incremental builds, the time taken to
  do two builds following a change is a lot less noticable than the time taken
  for periodic switches of a single build directory between debug and release
  mode.

Final thoughts on usability:

- Please don't write gdbsudo to /usr/local/bin without asking the user
  first. Instead I think it should default to $HOME/.local/bin, but with a
  prompt for the user to specify a path.

- While I realise your primary concern here is an interactive script, I'd
  tend towards requiring a cmdline arg to run in interactive mode and
  instead printing the help usage when run without parameters. Just a
  personal preference on my part though.

/Bruce