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.richard...@intel.com/
