From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mails.dpdk.org (mails.dpdk.org [217.70.189.124]) by inbox.dpdk.org (Postfix) with ESMTP id B4C00456E3; Mon, 29 Jul 2024 15:05:58 +0200 (CEST) Received: from mails.dpdk.org (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 68B0340678; Mon, 29 Jul 2024 15:05:58 +0200 (CEST) Received: from mgamail.intel.com (mgamail.intel.com [192.198.163.15]) by mails.dpdk.org (Postfix) with ESMTP id 0DBE240655 for ; Mon, 29 Jul 2024 15:05:55 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1722258356; x=1753794356; h=from:to:cc:subject:date:message-id:in-reply-to: references:mime-version:content-transfer-encoding; bh=N79rG2brKAYyJ+lxHHQG6jqZEjTl3cNWiM3zPDQFN4c=; b=Z0DUjCFdFD8gtBn+18UZwDKsXZg0pRztCC3suIg1DWwDLgZDPQvHG2H6 Amti+q6CjRYePcRlCUpna/eJMNkLn6Mrom4iRSEh22v2ADdcgl+848Afy BU1FWVn1mrJstLUyPNhmscDkoC5HdNUe2PTlqJhOumHWpbfWO6g5J6cpk LcIaeSrHxfmv7mMizxp37lYVPRbaas79o33Dqc3CzKIHDRbCxbGyaYH9O ANPdeW2tUqRipdHu1wN/glpz2mZRKGjVH2jGC0Ei3DmzPpnfUZVLPuimr rJ/B0T9fdJvCPbupUE2PoKi6ZcPuLSR7Ja+iFOnNtZbxeyaWVzH+t6iZU g==; X-CSE-ConnectionGUID: KZbpJ++9R6q961buceJllg== X-CSE-MsgGUID: aNUWuvV+SBWEqD2HRu5VfA== X-IronPort-AV: E=McAfee;i="6700,10204,11148"; a="20165608" X-IronPort-AV: E=Sophos;i="6.09,246,1716274800"; d="scan'208";a="20165608" Received: from orviesa010.jf.intel.com ([10.64.159.150]) by fmvoesa109.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 29 Jul 2024 06:05:55 -0700 X-CSE-ConnectionGUID: Rwl+4AnKTue8PQmsAZPC6w== X-CSE-MsgGUID: 7H5YseHpQWmQnSZncjMceQ== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="6.09,246,1716274800"; d="scan'208";a="53897645" Received: from silpixa00401119.ir.intel.com ([10.55.129.167]) by orviesa010.jf.intel.com with ESMTP; 29 Jul 2024 06:05:54 -0700 From: Anatoly Burakov To: dev@dpdk.org Cc: john.mcnamara@intel.com Subject: [RFC PATCH v2 0/1] Add Visual Studio Code configuration script Date: Mon, 29 Jul 2024 14:05:51 +0100 Message-ID: X-Mailer: git-send-email 2.43.5 In-Reply-To: References: MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces@dpdk.org 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 - I usually work as a local user not as root, so by default the script will attempt to use "gdbsudo" (a "sudo gdb $@" script in /usr/local/bin) for launch tasks, unless user specifically requests using gdb or is running as root With the above assumptions, the script is expected to work for basic DPDK configuration, as well as allow scripting any and all parts of it: - Any build configurations specified on the command-line will be added to the interactive configuration selector - Any apps/examples/drivers specified on the command-line will be selected by default in the interactive configuration selector - Any custom meson strings will also be filled in by default - When --no-ui is passed, all of the above parameters will be used to generate config as if the user has selected them There are a few usability issues with the script that are very difficult, if not impossible to solve for all cases, so a few other decisions have been made to hopefully address these issues for most cases. For starters, we can only know which apps/examples will get built after we create a build directory and process dependencies; we cannot infer this from our script. Therefore, by default all apps will get launch configurations created, even though these apps might not be built later. We could add another step after build to check config for missing apps and removing them, but it's difficult to do that without destroying any custom configuration user might have created. We remove generated configuration as it is! More importantly, our build system supports wildcards - for example, we can request "net/*" drivers to be built, and they will be built on a best-effort basis; that is, if the driver lacks a dependency, it will get ignored without any errors. For this script, a design decision has been made to handle internal driver dependencies (such as "net/ice" depending on "common/iavf") automatically to enhance user experience, until such time as the build system can do it better. However, the downside of this decision is that we need to handle dependencies between drivers for when user specifies wildcards on the command-line, which can be solved in three ways: * Not allow wildcards at all * Allow wildcards and always expand them * Allow wildcards and be smarter about handling them The first option is, IMO, inferior one: wildcards are convenient and quick to work with, so I would rather leave them as an option available to the user. The second options is nice, but it has a fundamental issue: when we expand very broad wildcards like "net/*", we will definitely cover a lot of drivers we do not have any dependencies for, but since we're now explicitly requesting them, the build will now error out if we requested something we didn't necessarily expect to be built. For this reason, I decided against this option. The third option is what I went with, with "smarter" being defined as follows: * User is allowed to use dialogs to edit configuration that is generated from parsing wildcard: if user changed something, we cannot keep wildcard any more and we assume user knows what they're doing and is OK with explicitly requesting compilation for drivers they selected. So, if user didn't change anything in the dialog, we keep the wildcard, otherwise we expand it. * If, by the time we get to resolving driver dependencies, we have wildcards in our driver param string, we see which drivers match this wildcard, and add wildcards for their dependencies. For example, if "net/ice" requires "common/iavf", and we have a "net/*" wildcard, one of the dependencies that we will add is "common/*". This behavior is, IMO, far better than the default one from our build system, where if a driver matches wildcard but cannot be built due to another internal dependency not being enabled (e.g. if "net/ice" is requested but "common/iavf" isn't requested), the build will fail to configure even though it would've been possible to build them otherwise So, explicitly enabled drivers get explicit dependencies, implicitly enabled drivers get implicit dependencies. The resulting build will be bigger than when using meson command line directly, but if the user is worried about build size, they can customize it via common meson parameters as well as being more granular about requested apps/examples/drivers. Thus, we address the "simple" usecase of "let's build everything by default", we handle some common use cases smarter than we otherwise would have, and we allow user to be as in-depth as they want by allowing to specify explicit meson command strings. I feel like this is a good compromise between usability and robustness. Please feel free to make any suggestions! [1] https://code.visualstudio.com/docs/remote/ssh Anatoly Burakov (1): devtools: add vscode configuration generator devtools/gen-vscode-config.py | 871 ++++++++++++++++++++++++++++++++++ 1 file changed, 871 insertions(+) create mode 100755 devtools/gen-vscode-config.py -- 2.43.5