On 7/30/2024 5:01 PM, Bruce Richardson wrote:
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..
Thanks, this looks very interesting! It's a shame it can't be done
without creating a build directory at all (e.g. by using meson dummy
runs or something), but like you said, better than nothing!
Regards,
/Bruce
[1]
https://patches.dpdk.org/project/dpdk/patch/20240730145508.551075-1-bruce.richard...@intel.com/
--
Thanks,
Anatoly
