On Tue, Jul 30, 2024 at 05:14:29PM +0200, Burakov, Anatoly wrote: > 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!
Yes. I was wracking my brains to find a better way to do this, but haven't come up with one yet.
