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

[Bruce Richardson <bruce.richardson@intel.com>]

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.