[RFC PATCH v2 0/1] Add Visual Studio Code configuration script

[Bruce Richardson]

On Mon, Jul 29, 2024 at 02:05:51PM +0100, Anatoly Burakov wrote:
> Lots of developers (myself included) uses Visual Studio Code as their primary
> IDE for DPDK development. I have been successfully using various incarnations of
> this script internally to quickly set up my development trees whenever I need a
> new configuration, so this script is being shared in hopes that it will be
> useful both to new developers starting with DPDK, and to seasoned DPDK
> developers who are already using Visual Studio Code. It makes starting working
> on DPDK in Visual Studio Code so much easier!
> 
> ** NOTE: Currently, only x86 configuration is generated as I have no way to test
>    the code analysis configuration on any other platforms.
> 
> ** NOTE 2: this is not for *Visual Studio* the Windows IDE, this is for *Visual
>    Studio Code* the cross-platform code editor. Specifically, main target
>    audience for this script is people who either run DPDK directly on their
>    Linux machine, or who use Remote SSH functionality to connect to a remote
>    Linux machine and set up VSCode build there. No other OS's are currently
>    supported by the script.
> 
> (if you're unaware of what is Remote SSH, I highly suggest checking it out [1])
> 
> Philosophy behind this script is as follows:
> 
> - The assumption is made that a developer will not be using wildly different
>   configurations from build to build - usually, they build the same things, work
>   with the same set of apps/drivers for a while, then switch to something else,
>   at which point a new configuration is needed
> 
> - Some configurations I consider to be "common" are included: debug build, debug
>   optimized build, release build with docs, and ASan build (feel free to make
>   suggestions here!)
> 
> - By default, the script will not add any meson flags unless user requested it,
>   however it will create launch configurations for all apps because not
>   specifying any flags leads to all apps being enabled
> 
> - All parameters that can be adjusted by TUI are also available as command line
>   arguments, so while user interaction is the default (using whiptail), it's
>   actually not required and can be bypassed
> 

The management of dependencies of components to be built is obviously a
tricky area here, when specifying e.g. enable_drivers flags. It may be
possible to improve the situation in meson itself, but that probably
requires massive rework of the lib/meson.build, drivers/meson.build and
app/meson.build files to process the subdirs and save the results for later
use (effectively process them twice within the restrictions of meson only
allowing subdir once).

In the meantime, as a better-than-nothing improvement, I've pushed a draft
patch to have meson produce a dependencies file as part of its processing[1].
That may be of use to you in doing new versions of the TUI - i.e. in the
background you could run a dummy meson config to /tmp and then process the
resulting deps file from it, to allow you to recursively enable
dependencies of the user-selected components..

Regards,
/Bruce

[1] https://patches.dpdk.org/project/dpdk/patch/20240730145508.551075-1-bruce.richardson@intel.com/