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

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

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

-- 
Thanks,
Anatoly