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 E58F5456F7; Tue, 30 Jul 2024 14:04:03 +0200 (CEST) Received: from mails.dpdk.org (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 8805A4025C; Tue, 30 Jul 2024 14:04:03 +0200 (CEST) Received: from mgamail.intel.com (mgamail.intel.com [192.198.163.7]) by mails.dpdk.org (Postfix) with ESMTP id C0F04400D7 for ; Tue, 30 Jul 2024 12:32:18 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1722335539; x=1753871539; h=date:from:to:cc:subject:message-id:references: in-reply-to:mime-version; bh=HNRsQD0i5YygckvFp88tpROi2CHQClL1wMI7YhfezNA=; b=E9UH+bi9ImdAxehiJFAgC32kNJMI09WyjzOKWwlf8wGHQzp7HXMmRvjK 6rHTEfFtBBOtM9asjqmViuwiPEQ7sMeX4meyln14TA6u3vMU5Zf/cqLvO p8ZnO/RV7crOGjRQLl+o/1jaGd7A/l40Bu2J8MZbpHuzBQKk25C8cR4PC 2rKPeZ5mKJoMtjF4P0JaMhwQtOZ1CV29gkzfTc7eylcODmStxSE8qVDSV QLxCBalck9KMGi7NVjVVr9I0CfxuQRIXlfjhMt7E+xY3V6M/MGc1x3bpm aq544z8+IVWQi8kzOvj+ffzeeg5SpIlwLiBTmUrmb/jJd4a4TEjRYCyAC g==; X-CSE-ConnectionGUID: 6p8hryZFQCq9wWkkqPlQLw== X-CSE-MsgGUID: DDRXbmWUSByVV3F2LYmAJA== X-IronPort-AV: E=McAfee;i="6700,10204,11148"; a="45558599" X-IronPort-AV: E=Sophos;i="6.09,248,1716274800"; d="scan'208";a="45558599" Received: from fmviesa010.fm.intel.com ([10.60.135.150]) by fmvoesa101.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 30 Jul 2024 03:32:13 -0700 X-CSE-ConnectionGUID: ZTdejQtxQJmuPX0rNKzeyA== X-CSE-MsgGUID: Zvsj+f3ERbWDuEN7K3FzRQ== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="6.09,248,1716274800"; d="scan'208";a="54345462" Received: from fmsmsx602.amr.corp.intel.com ([10.18.126.82]) by fmviesa010.fm.intel.com with ESMTP/TLS/AES256-GCM-SHA384; 30 Jul 2024 03:32:13 -0700 Received: from fmsmsx610.amr.corp.intel.com (10.18.126.90) by fmsmsx602.amr.corp.intel.com (10.18.126.82) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2507.39; Tue, 30 Jul 2024 03:32:12 -0700 Received: from fmsedg601.ED.cps.intel.com (10.1.192.135) by fmsmsx610.amr.corp.intel.com (10.18.126.90) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2507.39 via Frontend Transport; Tue, 30 Jul 2024 03:32:12 -0700 Received: from NAM12-DM6-obe.outbound.protection.outlook.com (104.47.59.169) by edgegateway.intel.com (192.55.55.70) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.1.2507.39; Tue, 30 Jul 2024 03:32:12 -0700 ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=ZkjoJCA8At3PsMy5sUs8NY/zlZUlOByYcVJseDZiQJ+yoKnkMIoTCvRa1pWNpU0GbBIRB4GXrh6rrAWKgMjMPK/BGXgTyXckWhW6p0TtBc7M0q0pphGqFaOes7K/0mzvGYjiNZqvrONwHDdfuEHprBCOr7kwODj1yxedyI+mYjY8C+6fUt2mmoeYYKV2v8asRjuAQxreL2OCw5xRGf7w8kacUWQm+gNNasP9FsW7LWCcUDgvPcLyIgIGLrxg4wGjVnm81DmXZVV9/yzQXifE00VP/yceeM7O2ga3YAm5b2Wb2IFFBTYUmluPsxNiYyI6jPnXH7pVAkaZ3F0HSPI6qQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=mU/mkJnG2h+tsVMEcJyEpJTuYnS06sDz5PU21A7Xx1A=; b=gH2b+AoAFw6LGqR5ItDa++iOX3og9UmmjgSJ4rDxliIkkTyVrWZ+8imbEVEnANhOn4HCUhYfHv85yMHsE1dlstv0T0g+vGSXM/4MPgnPbRAeEuhEz81YAvCMhYR5yji2CydF6bTu3KjCtN5PyVkesIuaSGqFEC85KN/BzdL0S/ScbwFe8cePJtGIKhNaDYL/TSZamV+K0NMd2WOsHfjjz6KzL3U7dWh81XMhnjZm0SIQNuvgmUf7PJlCHrQM9pMg7FqCaY+nxJ59oJjmga7T+432/lvZcRyYjr5lHI8FuXD2mkFvoAzLzrHul361bdPOHgBhfJLa7UPqWIgHxKPkoQ== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=intel.com; dmarc=pass action=none header.from=intel.com; dkim=pass header.d=intel.com; arc=none Authentication-Results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=intel.com; Received: from DS0PR11MB7309.namprd11.prod.outlook.com (2603:10b6:8:13e::17) by IA1PR11MB7387.namprd11.prod.outlook.com (2603:10b6:208:421::9) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.7807.27; Tue, 30 Jul 2024 10:32:04 +0000 Received: from DS0PR11MB7309.namprd11.prod.outlook.com ([fe80::f120:cc1f:d78d:ae9b]) by DS0PR11MB7309.namprd11.prod.outlook.com ([fe80::f120:cc1f:d78d:ae9b%2]) with mapi id 15.20.7807.026; Tue, 30 Jul 2024 10:32:04 +0000 Date: Tue, 30 Jul 2024 11:31:58 +0100 From: Bruce Richardson To: "Burakov, Anatoly" CC: , Subject: Re: [RFC PATCH v2 1/1] devtools: add vscode configuration generator Message-ID: References: <99003582461c7ec772e49dae9b43840496342646.1722258213.git.anatoly.burakov@intel.com> <3edc6421-0923-4371-a7dd-62d3857259ab@intel.com> <17a028f0-6c2e-493b-9fd4-3ded156299ac@intel.com> Content-Type: text/plain; charset="us-ascii" Content-Disposition: inline In-Reply-To: <17a028f0-6c2e-493b-9fd4-3ded156299ac@intel.com> X-ClientProxiedBy: DUZPR01CA0272.eurprd01.prod.exchangelabs.com (2603:10a6:10:4b9::12) To DS0PR11MB7309.namprd11.prod.outlook.com (2603:10b6:8:13e::17) MIME-Version: 1.0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: DS0PR11MB7309:EE_|IA1PR11MB7387:EE_ X-MS-Office365-Filtering-Correlation-Id: 50dd0168-0285-47cd-5549-08dcb082dab6 X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|366016|1800799024|376014; X-Microsoft-Antispam-Message-Info: =?us-ascii?Q?lHOp51skbPbShL+7GeRC3A+tlFqMbSW0Ppvqc6tIeM7ziAXtzGdV76ukiUQI?= =?us-ascii?Q?DY7xJ5ZEy+WnASW2n+Ny/+0DHfnM1PKZ1J/UVyex2cGNhZALVeN7NjCU+etn?= =?us-ascii?Q?n1o+97BEgZq+m7SA4xhb/nninex+tg8ejzj503rC+aV07Fp7gpsyxA8wWDFF?= =?us-ascii?Q?2ac2OCmW6mB2Z3d2IVCntbn5jeL/Rc1U+WeTL2ZKxSgXNlTY6SW79UoMi4MS?= =?us-ascii?Q?6yQ1oqkbAhelS0PmyjVvybmXW/umt6NPOnAEdQH9URdSGDX7yz4r57TcItUQ?= =?us-ascii?Q?Z95Wd/0x21wQ40RoH61loVR5X3ZtuftTubNw5wZtt9bbpwOIaS8cjAHJzhuG?= =?us-ascii?Q?aAlSCsjAS/AzaNuBxNqMzEAbTonG1x+9jMMfqT3QEq1XMBOuXleVIk9aNALn?= =?us-ascii?Q?g8oCdfc5hTxAslW7HMC8x3tBqHJn6HYd44KdgeKtTDvbXlTFOce3qIXFxHCO?= =?us-ascii?Q?/RBPqLs85/HUZZGj64tbasLD34riR2B8tZP3qpnwcY+HvftnQyCMSIAH5Haz?= =?us-ascii?Q?joLTlYTNESe9BsJcKSqmpOupsek/RueM+soXl8ixasWRzFbfVimZk+PuTJQu?= =?us-ascii?Q?B/ZKKspVJXb3qbUZm8O/hrhp/HQWyibFivG/DP4oPHsED/jgHVjWdRdIgTT6?= =?us-ascii?Q?pgI6JQxLb19tHDQRML/W2fvgQXERqFPamORdUClEL9vS2kygQUtQt+IBKM2j?= =?us-ascii?Q?3I9L291xM7OMuLmMWlQWrKUlAAwgILFW8elLxORCVnl7pumZN8sAR1fDMHKl?= =?us-ascii?Q?Tglb8vhcdshO6VUmsbm+7ndp2eah/eZFzeTTpnJKOlgaNa5VI9FFtD5EbcSG?= =?us-ascii?Q?0v4VDSdIckwWM0BNTOMTBiAi0BxAXMcE4cbRoVmdumSY2YuOy3vSpyE+b9/N?= =?us-ascii?Q?UYNib+evuYMQ6JLOOGEeKe29UtdWo+X/XyEQFSZeB0KCSW9z6nKCQ8GIDGVt?= =?us-ascii?Q?YTotP3BDkdB/lj201FEzy/2RLn+q3TwBpN05B9B06ofgXVGjulossD6PA8fD?= =?us-ascii?Q?VEvpHCsAe4EJRnmz3hLHXJwI0r4O44jANnJ2CPaF8Qbeq59F48vMDftsBSDp?= =?us-ascii?Q?rxMxNUODzC1Kg/c3DXRI/K1TKDakEtjmKNbDOE2wYlNLzE711XVPwq+OdOCe?= =?us-ascii?Q?lxjEb7TqRZpb589I9z/0jv9CcdV79NXUiLmLjSw22ZoAJww8cXfxpbKDUntT?= =?us-ascii?Q?r0K1l78FHOvLQpkSGu+vtJCoe4LUw9jB4037A2+/6FaSZBdTz1S+n/lHczzB?= =?us-ascii?Q?yrx5QIqCjfNdyFth6bhPolSxLfblgtLBndJfIYTFU1+n/zGkrv+Zv5bGZWM9?= =?us-ascii?Q?PWQ=3D?= X-Forefront-Antispam-Report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:DS0PR11MB7309.namprd11.prod.outlook.com; PTR:; CAT:NONE; SFS:(13230040)(366016)(1800799024)(376014); DIR:OUT; SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?us-ascii?Q?EWkM43A/Ob/eoYApO2GBywIYqWywb08Q8JaYsaxHwiXFRUImOM9BwNCtXNAX?= =?us-ascii?Q?+cIQvMzooVEnL/JeMcpeNdQruztXvUoNeQ9OlnHIw0eqVDb4+I+GhXeUb9qr?= =?us-ascii?Q?F5IyK+orKf5gJspDR9h3ySM4kioVLOzk1/9fA/P0mAa0gR/eDaMRHRWQMEqC?= =?us-ascii?Q?wJcZ5VLpw1JyrU585MjurAFqRS9kyoWbuhbp07Z6cvkg6iC88pxcPvrNyDg7?= =?us-ascii?Q?b7R4vwKsK6Y3z/qHXkXfo8mGTPPW//8YgQwmv9zFLUblUZMO2EsnZf1982Jz?= =?us-ascii?Q?z8e4SOFlnP/amijFTFHgRD2pdn+1zqmeIxnT+AAwLsuvAptuQzRPDC0Pev7m?= =?us-ascii?Q?gX37fqYGQMP0kWi1d4oOfQPfoNxT1ZMtX96YJ5QROMwrU3p+fWnNxnKnnBj6?= =?us-ascii?Q?ugH6mX2+96zVzyvgv1ikE5D7iPR7DEFJpokjzbAK/364WtAhEOPRtli7bGlH?= =?us-ascii?Q?zU8oZb4RJclvPBt5sYnrLrfwO8cgtLpmEU1M1pv8ohgP6Cj6aAhcHPTsal4j?= =?us-ascii?Q?lwidk4rwDbLQurnYK/by2Cjs91dG6h1OovdgMF4iOCK2ZCSh6rtPbL1saX2p?= =?us-ascii?Q?e8afbmngGWq5GhGtp8nHftwK+shonGSEgH7lX66Gral7TjruTaGVc0/A/SV3?= =?us-ascii?Q?pyE5Yvl+rl4vNx2feNCXf6F7didn1EAN7RnabXMNltEOJFcwNPGA0Oxij1hX?= =?us-ascii?Q?7CqBgUb1pu1XDktv5jovs9Qsh6s5Wawx+Rh7NDsuqz5yHxfxZt7HSlAcBdZ9?= =?us-ascii?Q?0bPtkfk26LNJsLYchaT9sb9TOoN1k0loWuzSzI4AWY+X4hGrMhNwS7/rROia?= =?us-ascii?Q?AU90HEjF2Wy78HEZ8TIVcZK3pWEBRYvehDatTJ5oVWo7Alv0ipNbbKO3qDJW?= =?us-ascii?Q?7G5pEsoupKfUy1dLig553DxfemNJ+K402paGwpXcbAgWV7ZpgO+0KMpItScy?= =?us-ascii?Q?qpO56KQ28tCu/+c2+Fq23E6F8AvT2rZySF5M0kgyNeNiQrdsSDwa/icgaLSl?= =?us-ascii?Q?X4J3AOUjlEy1V/5f/WgjH30KOEjkPKDLe8BZaPw/JJK3qhyLT+5j0+Ga+7g4?= =?us-ascii?Q?z/kFu+GyLGD7FgsQYy5iZzNjuxASAX3AjbM01b7enmqsgET+M7O25kfj9fVX?= =?us-ascii?Q?70yqgkHkIT120zZ+MhljQDv6ArlIDdETrJHJAMoR57loEJzdRt4rMaQvoTYw?= =?us-ascii?Q?ttW3MyacXVjC2WM14389iq6tFP4CbPliBS2rKEWL/cfyqRwm8HBoRQlIpOP0?= =?us-ascii?Q?n9Jv3/bQNGXTUsx44Y14QN34xsJ7LBdpAnobQUudCukjx7EAtaBPd+lioH5Y?= =?us-ascii?Q?GME/nLlvs/rbswy7sf2C6bKEM6/mxVSDOfIddVHuaVrq1opTk9VF6tm4IfSy?= =?us-ascii?Q?CD6kk6JdMOeqqdQcjh7E2X57btz3CCc2ZrWcVSkrWVbwsczCbwxbyIlXJuJ4?= =?us-ascii?Q?nQHLrHVbBxLeUV4VfR2Q2VjeMr6AoMd/+AyzGohmK94px6QlAvIZS4y/JQ6t?= =?us-ascii?Q?Qf02Uax1W1MfHXw3raaZ8a86FSjjCVMfmW7r1DFZRnORw9jrHzFiPqa4kXtX?= =?us-ascii?Q?zhz3cl5yVbugq60lRBSTT/JgFilPI9XNGEWMVQTAvn04yZcb63kyjdTvPzjD?= =?us-ascii?Q?hw=3D=3D?= X-MS-Exchange-CrossTenant-Network-Message-Id: 50dd0168-0285-47cd-5549-08dcb082dab6 X-MS-Exchange-CrossTenant-AuthSource: DS0PR11MB7309.namprd11.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 30 Jul 2024 10:32:04.3533 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: 46c98d88-e344-4ed4-8496-4ed7712e255d X-MS-Exchange-CrossTenant-MailboxType: HOSTED X-MS-Exchange-CrossTenant-UserPrincipalName: /olZQ3IqepNhm+WHVLsFQPz/D4FArc7j3gZaF3fsE/VVh1Nu+2iDhToCEjrCA0WXkcGbFSO7t6a1lYhrlrnpsFHBjQE5RMynoETIYP77wM8= X-MS-Exchange-Transport-CrossTenantHeadersStamped: IA1PR11MB7387 X-OriginatorOrg: intel.com 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 On Tue, Jul 30, 2024 at 11:21:25AM +0200, Burakov, Anatoly wrote: > On 7/29/2024 6:41 PM, Bruce Richardson wrote: > > On Mon, Jul 29, 2024 at 06:16:48PM +0200, Burakov, Anatoly wrote: > > > On 7/29/2024 4:30 PM, Bruce Richardson wrote: > > > > On Mon, Jul 29, 2024 at 02:05:52PM +0100, Anatoly Burakov wrote: > > > > > A lot of developers use Visual Studio Code as their primary IDE. This > > > > > script generates a configuration file for VSCode that sets up basic build > > > > > tasks, launch tasks, as well as C/C++ code analysis settings that will > > > > > take into account compile_commands.json that is automatically generated > > > > > by meson. > > > > > > > > > > Files generated by script: > > > > > - .vscode/settings.json: stores variables needed by other files > > > > > - .vscode/tasks.json: defines build tasks > > > > > - .vscode/launch.json: defines launch tasks > > > > > - .vscode/c_cpp_properties.json: defines code analysis settings > > > > > > > > > > The script uses a combination of globbing and meson file parsing to > > > > > discover available apps, examples, and drivers, and generates a > > > > > project-wide settings file, so that the user can later switch between > > > > > debug/release/etc. configurations while keeping their desired apps, > > > > > examples, and drivers, built by meson, and ensuring launch configurations > > > > > still work correctly whatever the configuration selected. > > > > > > > > > > This script uses whiptail as TUI, which is expected to be universally > > > > > available as it is shipped by default on most major distributions. > > > > > However, the script is also designed to be scriptable and can be run > > > > > without user interaction, and have its configuration supplied from > > > > > command-line arguments. > > > > > > > > > > Signed-off-by: Anatoly Burakov > > > > > --- > > > > > > > > > Just was trying this out, nice script, thanks. > > > > > > Thanks for the feedback! Comments below. > > > More comments inline below, but summarising after the fact here. Still not entirely sure what way is best for all this so please take all current and previous suggestions with a pinch of salt. Based off what you suggest and the ongoing discuss my current thinking is: * +1 to split the vscode config generation from the TUI. Both are also targetting different end-users - the TUI is for everyone looking to build DPDK, both devs and users, while the vscode config is for developers only. * Let's ignore the multi-build-directory setup for now, if it makes it more complex for the simple cases of one build-dir. * I think we should investigate having the vscode config generated from meson rather than the other way around. See also below. /Bruce > > > > > > > > Initial thoughts concerning the build directory: > > > > - the script doesn't actually create the build directory, so there is no > > > > guarantee that the build directory created will have the same parameters > > > > as that specified in the script run. I'd suggest in the case where the > > > > user runs the script and specifies build settings, that the build > > > > directory is then configured using those settings. > > > > > > I'm not sure I follow. > > > > > > The script creates a command for VSCode to create a build directory using > > > configuration the user has supplied at script's run time. The directory is > > > not created by the script, that is the job of meson build system. This > > > script is merely codifying commands for meson to do that, with the > > > expectation that the user is familiar with VSCode workflow and will go > > > straight to build commands anyway, and will pick one of them. Are you > > > suggesting running `meson setup` right after? > > > > > > > Yes, that is what I was thinking, based on the assumption that running > > "meson setup" should be a once-only task. I suppose overall it's a > > different workflow to what you have - where you run meson setup repeatedly > > each time you change a build type. My thinking for the approach to take > > here is that your script firstly asks for a build directory, and then: > > * if build-dir exists, pull settings you need from there, such as build > > type and the apps being built. > > * if not existing, ask for config settings as you do now, and then run > > meson setup to create the build dir. > > I guess the disconnect comes from the fact that I treat meson build > directories as transient and disposable and never hesitate to wipe them and > start over, whereas you seem to favor persistence. Since 99% of the time I'm > using heavily reduced builds anyway (e.g. one app, one driver), repeatedly > doing meson setup doesn't really hinder me in any way, but I suppose it > would if I had more meaty builds. > It mainly just seems inefficient to me. Ninja does a lot of processing to minimise the work done whenever you make a configuration change, and you bypass all that by nuking the directory from orbit (only way to be sure!) and then creating a new one! The other main downside of it (to my mind), is that the tracking of settings for the build needs to be in vscode. I'd prefer meson itself to be the "one source of truth" and vscode to be tweaking that, rather than tracking everything itself. > I think we also have a slightly different view of what this script should be > - I envisioned a "one-stop-shop" for "open freshly cloned DPDK directory, > run one script and off you go" (which stems from the fact that I heavily > rely on Git Worktrees [1] in my workflow, so having an untouched source > directory without any configuration in it is something I am constantly faced > with), while you seem to favor picking up existing meson build and building > a VSCode configuration around it. > > I can see point in this, and I guess I actually unwittingly rolled two > scripts into one - a TUI meson frontend, and a VSCode configuration > generator. Perhaps it should very well be two scripts, not one? Because > honestly, having something like what I built for TUI (the meson > configuration frontend) is something I missed a lot and something I always > wished our long-gone `setup.sh` script had, but didn't, and now with meson > it's much simpler to do but we still don't have anything like that. Maybe > this is our opportunity to provide a quicker "quick start" script, one that > I could run and configure meson build without having to type anything. WDYT? > Splitting it into two makes sense to me, yes, since as you point out there are really two separate jobs involved here that one may want to roll with separately. > > > > Thereafter, the source for all build settings is not in vscode, but in > > meson, and you just use "meson configure" from vscode to tweak whatever > > needs tweaking, without affecting any other settings. Since you don't > > affect any other settings there is no need to record what they should be. > > Why would I be using meson configure from vscode then? I mean, the whole > notion of having tasks in VSCode is so that I define a few common > configurations and never touch them until I'm working on something else. If > I have to type in configure commands anyway (because I would have to, to > adjust configuration in meson), I might as well do so using terminal, and > avoid dealing with meson from VSCode entirely? > > (technically, there's a way to read arguments from a popup window - I > suppose we could have this step recorded as a VSCode task) > The reason I was thinking about this is that you don't want to expose dozens of tasks in vscode for tweaking every possible meson setting. Sure, have build and run tasks for the common options, but for "advanced use" where the user wants to tweak a build setting, let them just do it from commandline without having to re-run a config script to adjust the settings. > > > > > > > > - Finally, and semi-related, this script assumes that the user does > > > > everything in a single build directory. Just something to consider, but > > > > my own workflow till now has tended to keep multiple build directories > > > > around, generally a "build" directory, which is either release or > > > > debugoptimized type, and a separate "build-debug" directory + occasionally > > > > others for build testing. When doing incremental builds, the time taken to > > > > do two builds following a change is a lot less noticable than the time taken > > > > for periodic switches of a single build directory between debug and release > > > > mode. > > > > > > The problem with that approach is the launch tasks, because a launch task > > > can only ever point to one executable, so if you have multiple build > > > directories, you'll have to have multiple launch tasks per app/example. I > > > guess we can either tag them (e.g. "Launch dpdk-testpmd [debug]", "Launch > > > dpdk-testpmd [asan]" etc.), or use some kind of indirection to "select > > > active build configuration" (e.g. have one launch task but overwrite > > > ${config:BUILDDIR} after request for configuration, so that launch tasks > > > would pick up actual executable path at run time from settings). I would > > > prefer the latter to be honest, as it's much easier to drop a script into > > > ./vscode and run it together with "configure" command to switch between > > > different build/launch configurations. What do you think? > > > > > > > I think I'd prefer the former actually - to have explicit tasks always > > listed for debug and release builds. > > Not a big deal for me either way, I'll just hack in the extra tasks as I > > need them, so it's a low-priority support item for me. > > There's another issue though: code analysis. If you have multiple build > directories, your C++ analysis settings (the .vscode/c_cpp_properties.json > file) can only ever use one specific compile_commands.json from a specific > build directory. I think if we were to support having multiple build dirs, > we would *have to* implement something like "switch active configuration" > thing anyway. > Strictly speaking, yes. However, in my experience using eclipse as an IDE in the past it doesn't matter that much which or how many build directories are analysed. However, vscode may well be different in this regard. Since I don't ever envisage myself doing everything always through vscode, I'm happy enough with vscode managing a single build directory, and I can manually worry about a second build directory myself. Maybe let's park the multi-build-dir stuff for now, unless others feel that it's something they need. > Whether we add tagged launch tasks is honestly a problem to be solved, > because on the one hand we want them to be generated automatically (ideally > after configure step), and on the other we also want to not interfere with > any custom configuration the user has already added (such as e.g. command > line arguments to existing launch tasks). We'll probably have to do config > file parsing and updating the configuration, rather than regenerating it > each time. Python's JSON also doesn't support comments, so for any comments > that were added to configurations, we'd either lose them, or find a way to > reinsert them post-generation. > Have you considered generating the launch tasks from a script launched from meson itself? Any time the configuration is changed, meson will re-run at the next build and that can trigger re-generation of whatever vscode config you need, including launch tasks for all the binaries. This would be another advantage of splitting the script into two - one should look to make the vscode-settings generation script usable from meson. > It sounds like this would really be something that a setup script would do > better than a VSCode config generator. > > So, assuming we want to move setup steps to another script and concentrate > on VSCode configuration exclusively, my thinking of how it would work is as > follows: > > 1) Assume we want multiple build directories, suggest automatically picking > them up from source directory but support specifying one or more from > command line arguments (or TUI, although I suspect if setup moves to a > separate script, there's very little need for TUI in VSCode config generator > - it should be a mostly mechanical process at that point) > I'm probably an outlier, so lets not over-design things for the multi-build-directory case. If we think about generating the vscode config from a meson run (via a "generate-vscode-config" setting or something), that may switch the way in which things are actually being done. In that case, a build directory would register itself with the vscode config - creating a new one if not already present. > 2) Now that we track multiple build directories, we can store them in a YAML > file or something (e.g. .vscode/.dpdk_builds.yaml), and create tasks to > switch between them as "active" to support e.g. different code analysis > settings and stuff like that > Initially, maybe don't add this. For first draft supporting multi-directories, I'd start by adding prefixed duplicate tasks for each directory registered. > 3) All build tasks can work off "active configuration" which means we don't > need multiple compile tasks, but for launch tasks we may need different ones > because different build dirs may have different launch tasks > Again, I'd just add tasks rather than bothering with active configs. > Let's assume user just ran `meson configure` and changed something about one > of their configurations. What do you think should happen next? I mean, if > they added/removed an app/example to the build, we can detect that and > auto-generate (or remove) a launch task, for example? Or do you think it > should be a manual step, e.g. user should explicitly request > regenerating/updating launch tasks? Maybe there should be an --update flag, > to indicate that we're not creating new configurations but merely refreshing > existing ones? See above, this is a case where having the vscode config script callable from meson would be perfect. > > [1] https://git-scm.com/docs/git-worktree > Thanks for the link - seems to be automating a setup which I've been approximately doing manually for some years now! :-)