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.bura...@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
