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

["Burakov, Anatoly" <anatoly.burakov@intel.com>]

On 7/30/2024 12:31 PM, Bruce Richardson wrote:
> On Tue, Jul 30, 2024 at 11:21:25AM +0200, Burakov, Anatoly wrote:
>> On 7/29/2024 6:41 PM, Bruce Richardson wrote:
>>> On Mon, Jul 29, 2024 at 06:16:48PM +0200, Burakov, Anatoly wrote:
>>>> On 7/29/2024 4:30 PM, Bruce Richardson wrote:
>>>>> 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.
>>>>
>>>> Thanks for the feedback! Comments below.
>>>>
> 
> More comments inline below, but summarising after the fact here.
> 
>   Still not entirely sure what way is best for all this so please take all
> current and previous suggestions with a pinch of salt. Based off what you
> suggest and the ongoing discuss my current thinking is:
> 
> * +1 to split the vscode config generation from the TUI. Both are also
>    targetting different end-users - the TUI is for everyone looking to build
>    DPDK, both devs and users, while the vscode config is for developers only.
> * Let's ignore the multi-build-directory setup for now, if it makes it more
>    complex for the simple cases of one build-dir.

Not really *that* much more complex, IMO. The only real issue is 
possible differences in code analysis behavior stemming from having 
"wrong" build directory set up as a source of compile_commands.json. If 
you're OK with adding multiple tasks per multiple build directories, 
then all of the rest of it becomes trivial because if launch tasks are 
per-build, they can reference per-build build commands and work 
seamlessly using "duplicate" commands.

And even then, for first version we can probably drop the code analysis 
angle (just use the first detected config as the source), in which case 
we can pretty much support multiple build dirs for free as we'd have to 
build all the infrastructure (e.g. config updates etc.) anyway if we 
want this process to be seamless.

> * I think we should investigate having the vscode config generated from
>    meson rather than the other way around.

It didn't occur to me that it was possible, it sounds like that's really 
the way to go!

<snip>


> Strictly speaking, yes. However, in my experience using eclipse as an IDE
> in the past it doesn't matter that much which or how many build directories
> are analysed. However, vscode may well be different in this regard.

Unless the user does *wildly* different things in their build 
directories (i.e. two dirs, one of which used for cross-build or 
something), I expect things to work without any additional effort, so 
you're right in that for most practical purposes, the result wouldn't 
really be different to having "proper" C++ analysis configurations.

> Since I don't ever envisage myself doing everything always through vscode,
> I'm happy enough with vscode managing a single build directory, and I can
> manually worry about a second build directory myself.  Maybe let's park the
> multi-build-dir stuff for now, unless others feel that it's something they
> need.

Well, I do strive to do most things with VSCode (that's why I had 
multiple configurations to begin with!), so it would benefit *my* 
workflow to support that :)

-- 
Thanks,
Anatoly