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

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

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

- I usually work as a local user not as root, so by default the script will
  attempt to use "gdbsudo" (a "sudo gdb $@" script in /usr/local/bin) for launch
  tasks, unless user specifically requests using gdb or is running as root

With the above assumptions, the script is expected to work for basic DPDK
configuration, as well as allow scripting any and all parts of it:

- Any build configurations specified on the command-line will be added to the
  interactive configuration selector

- Any apps/examples/drivers specified on the command-line will be selected by
  default in the interactive configuration selector

- Any custom meson strings will also be filled in by default

- When --no-ui is passed, all of the above parameters will be used to generate
  config as if the user has selected them

There are a few usability issues with the script that are very difficult, if not
impossible to solve for all cases, so a few other decisions have been made to
hopefully address these issues for most cases.

For starters, we can only know which apps/examples will get built after we
create a build directory and process dependencies; we cannot infer this from our
script. Therefore, by default all apps will get launch configurations created,
even though these apps might not be built later. We could add another step after
build to check config for missing apps and removing them, but it's difficult to
do that without destroying any custom configuration user might have created. We
remove generated configuration as it is!

More importantly, our build system supports wildcards - for example, we can
request "net/*" drivers to be built, and they will be built on a best-effort
basis; that is, if the driver lacks a dependency, it will get ignored without
any errors. For this script, a design decision has been made to handle internal
driver dependencies (such as "net/ice" depending on "common/iavf") automatically
to enhance user experience, until such time as the build system can do it
better. However, the downside of this decision is that we need to handle
dependencies between drivers for when user specifies wildcards on the
command-line, which can be solved in three ways:

* Not allow wildcards at all
* Allow wildcards and always expand them
* Allow wildcards and be smarter about handling them

The first option is, IMO, inferior one: wildcards are convenient and quick to
work with, so I would rather leave them as an option available to the user.

The second options is nice, but it has a fundamental issue: when we expand very
broad wildcards like "net/*", we will definitely cover a lot of drivers we do
not have any dependencies for, but since we're now explicitly requesting them,
the build will now error out if we requested something we didn't necessarily
expect to be built. For this reason, I decided against this option.

The third option is what I went with, with "smarter" being defined as follows:

* User is allowed to use dialogs to edit configuration that is generated from
  parsing wildcard: if user changed something, we cannot keep wildcard any more
  and we assume user knows what they're doing and is OK with explicitly
  requesting compilation for drivers they selected. So, if user didn't change
  anything in the dialog, we keep the wildcard, otherwise we expand it.

* If, by the time we get to resolving driver dependencies, we have wildcards in
  our driver param string, we see which drivers match this wildcard, and add
  wildcards for their dependencies. For example, if "net/ice" requires
  "common/iavf", and we have a "net/*" wildcard, one of the dependencies that we
  will add is "common/*". This behavior is, IMO, far better than the default one
  from our build system, where if a driver matches wildcard but cannot be built
  due to another internal dependency not being enabled (e.g. if "net/ice" is
  requested but "common/iavf" isn't requested), the build will fail to configure
  even though it would've been possible to build them otherwise

So, explicitly enabled drivers get explicit dependencies, implicitly enabled
drivers get implicit dependencies. The resulting build will be bigger than when
using meson command line directly, but if the user is worried about build size,
they can customize it via common meson parameters as well as being more granular
about requested apps/examples/drivers. Thus, we address the "simple" usecase of
"let's build everything by default", we handle some common use cases smarter
than we otherwise would have, and we allow user to be as in-depth as they want
by allowing to specify explicit meson command strings. I feel like this is a
good compromise between usability and robustness.

Please feel free to make any suggestions!

[1] https://code.visualstudio.com/docs/remote/ssh

Anatoly Burakov (1):
  devtools: add vscode configuration generator

 devtools/gen-vscode-config.py | 871 ++++++++++++++++++++++++++++++++++
 1 file changed, 871 insertions(+)
 create mode 100755 devtools/gen-vscode-config.py

-- 
2.43.5