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 744F4456EE; Tue, 30 Jul 2024 12:28:16 +0200 (CEST) Received: from mails.dpdk.org (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 027614025C; Tue, 30 Jul 2024 12:28:16 +0200 (CEST) Received: from mgamail.intel.com (mgamail.intel.com [192.198.163.13]) by mails.dpdk.org (Postfix) with ESMTP id 90459400D7 for ; Tue, 30 Jul 2024 11:21:44 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1722331305; x=1753867305; h=message-id:date:subject:to:cc:references:from: in-reply-to:content-transfer-encoding:mime-version; bh=boNgVFcBkpZIrF+UrAUOH2FQZBVxA/tukRocwTmpwdA=; b=HOmIwWwkA8GYrDlZfxQ2DnBAvfolWiZTBKYJ4uV9n+aGjBBXdtGE0v9w fK5pTJ1cXxtkRF8MoUX9Iqedv8pEvjvT7fMj2lG9le3DxnpOhV13PfpFG 1XvU63zmkeAhLAzM+K5I5+Dw4dvw9SitG2ENYFGfXhMUuQDsSm54ysukb Ube/eO6aUYRPyUNrHEbfbW8AOT8O5vMklmfp66BQOCjGClBRMxHfom4ql tDi08NJqOMjQldYYi/KYg5HlWRqdzyQBJJCm3Zm/OriNrvTvOlK0LytoN 9xG0qPvLTRqN3NvL8/ruM1I/eTigof3UvDchA+9RuycBb/H6ywpKac97o g==; X-CSE-ConnectionGUID: wlxvQxnWSwuWOQQC9+3vuQ== X-CSE-MsgGUID: qhntcJZPT5yOQvcToU9h9w== X-IronPort-AV: E=McAfee;i="6700,10204,11148"; a="23051250" X-IronPort-AV: E=Sophos;i="6.09,248,1716274800"; d="scan'208";a="23051250" Received: from fmviesa006.fm.intel.com ([10.60.135.146]) by fmvoesa107.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 30 Jul 2024 02:21:39 -0700 X-CSE-ConnectionGUID: E5weP7wzS1ypc25+6KHEMQ== X-CSE-MsgGUID: nnGQ5KeoRBueNSh4e/pBxQ== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="6.09,248,1716274800"; d="scan'208";a="53940886" Received: from orsmsx603.amr.corp.intel.com ([10.22.229.16]) by fmviesa006.fm.intel.com with ESMTP/TLS/AES256-GCM-SHA384; 30 Jul 2024 02:21:39 -0700 Received: from orsmsx610.amr.corp.intel.com (10.22.229.23) by ORSMSX603.amr.corp.intel.com (10.22.229.16) 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 02:21:38 -0700 Received: from ORSEDG601.ED.cps.intel.com (10.7.248.6) by orsmsx610.amr.corp.intel.com (10.22.229.23) 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 02:21:38 -0700 Received: from NAM11-BN8-obe.outbound.protection.outlook.com (104.47.58.169) by edgegateway.intel.com (134.134.137.102) 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 02:21:36 -0700 ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=KVSKwlVV4Sb1zXOYSgikrG0GsSOmu71uI/kgvJkNEOZDeJP8SBWjcQpIHK88DOg+QJm/LsqASd41GzNCEQwD/9t9ctP8gu4w7rzmqZ+vHGcKXf3dxz4TpfrfhLqb9OuTI7v1uje2IYhljTysCcfS+cYSRdJOPkd11Hqu29IPZeEs839sG7M8jVrcHnhntfTjVqjLJDzf0zRAmcD1itgFozI2hBZXIAvbT9RA0ZzmdMknL8kMVbHyrL5HlfB3SBmmdN4lQn65NWVsd8HxI+hx0alCIpukPw1oYBl4G8kRLguKEPFDBY9sV59Qx+PRSVY+0ak24Pz6SH4dMVo1P1X4uA== 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=vZ+Pk2PyzpbnN0sgkEtBqa5z+zKN9umOqRc20uKVGq4=; b=dMbGDarQSKLoyRzG7V8fl8pJeALEakEX76df9Kx7dwhwEz68nh33AV8O9q3Oxy/SMFDhIlEFRWzwbbGj2cjrz+p+MzbiPe1sCvqvtQ9Zwsw2Jfp/xGjO9GkvVU2SKmxtGchaAym0dqWTk5dtvj/MwnPydHfXqxbt6SUOlbsDyoOTtcp8fLmXg+325p1V0gpKZhOQeLYHcrTQkd3lR++wZBB1g6CkjHFb8kEwZYyXP2/8B/DEEjncQiH+93C0eC5hRoVym87zvu08j2xGXUMvNjA3Mi7eJnvHplH44NmFBR4H+ukDDs0ldYAHGda41cC+aYXXuEjttw2T5r5Bv2uvUA== 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 DM4PR11MB6502.namprd11.prod.outlook.com (2603:10b6:8:89::7) by SN7PR11MB6946.namprd11.prod.outlook.com (2603:10b6:806:2a9::16) 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 09:21:34 +0000 Received: from DM4PR11MB6502.namprd11.prod.outlook.com ([fe80::21e4:2d98:c498:2d7a]) by DM4PR11MB6502.namprd11.prod.outlook.com ([fe80::21e4:2d98:c498:2d7a%7]) with mapi id 15.20.7828.016; Tue, 30 Jul 2024 09:21:34 +0000 Message-ID: <17a028f0-6c2e-493b-9fd4-3ded156299ac@intel.com> Date: Tue, 30 Jul 2024 11:21:25 +0200 User-Agent: Mozilla Thunderbird Subject: Re: [RFC PATCH v2 1/1] devtools: add vscode configuration generator To: Bruce Richardson CC: , References: <99003582461c7ec772e49dae9b43840496342646.1722258213.git.anatoly.burakov@intel.com> <3edc6421-0923-4371-a7dd-62d3857259ab@intel.com> Content-Language: en-US From: "Burakov, Anatoly" In-Reply-To: Content-Type: text/plain; charset="UTF-8"; format=flowed Content-Transfer-Encoding: 7bit X-ClientProxiedBy: DB9PR01CA0027.eurprd01.prod.exchangelabs.com (2603:10a6:10:1d8::32) To DM4PR11MB6502.namprd11.prod.outlook.com (2603:10b6:8:89::7) MIME-Version: 1.0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: DM4PR11MB6502:EE_|SN7PR11MB6946:EE_ X-MS-Office365-Filtering-Correlation-Id: 3d2d1f20-ea70-42d9-2d5e-08dcb0790135 X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|1800799024|376014|366016; X-Microsoft-Antispam-Message-Info: =?utf-8?B?OWdMWE9DQ1Jxbmc1VWt2WEJoSEhSN1pzeVZVT081NzVkNGdEaFB2MFR5SG9S?= =?utf-8?B?TXRyMndJSGs1aE1jUlU0UlN1N0xtcU0wT0hDYWh5Q1VIM2YrRU9LaGI3RU5O?= =?utf-8?B?aEE2SVg0S1lPUzRBWmQxYUJZQU9zclB0WHlXMGtwaG91TXp5V2JDRCtoTi9B?= =?utf-8?B?UFV5VDI0N1R0MDV0UUV0cnd5UHNZNGdURGlZaFh3aGtrZW5NUVBJTFpQczhj?= =?utf-8?B?dXNOdnc3clgvamNsc0Nobjk0MjdFR2ZWUGdxdGloeWhCbThBa0ZmemxMSmJJ?= =?utf-8?B?RU9QRDRTR2h2S05lVVRhME4rZm5pSldKTXRmS2d2Z1NtZ3dkdTVrN01QaUlh?= =?utf-8?B?TmU3d0dseUE1V3VlTGZzQ1k1R3duOTE2QmIyQVQrOTRZV0RtS3VsS3BzUWhk?= =?utf-8?B?RTFqOGpmbjlOd2krV1pRZ1pHVWh5L3ZlaWxCWFVpWWNmb3l0UWlKV09LeWg3?= =?utf-8?B?blVYejg2QWRSM0lvdlRaczhOcWNPYzkwcDkrQ3ExRmE0TnpvcnNrdnFIN1BS?= =?utf-8?B?QjZVRENYYVg4aUthT0NZY3k1SDZldUNtSDRZMG5udW91a3RwY0xxV0JxTUdQ?= =?utf-8?B?a0JoY0NVTnlYM01ucXhEOUhadUFabDVIOWhUTW9Lb0lWRHNTU1BWSDVnMmdu?= =?utf-8?B?eVNCV3lNclZCMng4cmw0RlcwUndrZWZoYysxYUFDd3RwUUxsRGMxTlJiVndB?= =?utf-8?B?NWp0Nnl2OU42bHNKWkhXTlp5aGdFSFVhdXZjTEhENFZXRlRBV1RXbm92c1Zu?= =?utf-8?B?Rk8xU3NlYUtFSmhBWDVFTTRPV3d4K08zWndYTGYwVVoyN3c4MnNROTFSWm9R?= =?utf-8?B?T1drK1B4eVdkeTZIOXZBT2xuMkVqMTBLYi9qMkFWb0tWNWRCQlZtYUVyeFdF?= =?utf-8?B?Qm9LWTJJaTVJQUhoc2g3aGRKeGQxdHJma3E1TDlHQWI1WE1UcUdZUEFXUVdp?= =?utf-8?B?MU16cnlDTDByWklLWC8vclVoa0VJS3FnWnNNSmFQY3duVGRUSG45TU0yOHk0?= =?utf-8?B?MVF6UHBudHkydmRJTTNrRllWdmlGakVwT0J1SlgrYkJYTDg2SUJDWEFoMVI1?= =?utf-8?B?d2dyN1VLZTVNRkNFa0JGRU03RzBLT0t3VWZoUys3S1BUKzYxUmZYMjdsWjd2?= =?utf-8?B?bEFWamYrUi9aa3hsZ3R1bi9uaHlHQ2dvSUhORjBvSkFGZkpFT3IzcVU5c08x?= =?utf-8?B?TnR3TEo5aHIzbDA4T2o0T2hkSmFKNnRJMkkrV3VoNFFXTXplSWxpWTVXMm9U?= =?utf-8?B?ejkvdDh6UWl2Y0dHZDBHbWZpN2NidVV4WE1mdnJNMjJTZWdKaHVlMzV1SE1T?= =?utf-8?B?MVQ0M2YvcjFvQTJTaFFNS0hFUXJzQUMvcEt2U091WEMrcTNCOWd6eXdsdDNa?= =?utf-8?B?Q1ZucUtEU0p1ZUpOSGJ2WmpURWpZcDRqWVl0Y282d0hXS2JFVkdvMWJHS21J?= =?utf-8?B?SHpUTlNDMm9nODY1Y2FQYlRVWWNkQzVSaHRPaGZFN2l0c21PZ05SeGJUNHNr?= =?utf-8?B?YjVsQkhKcXF3WkE3SGQyTnEwdlpSTjVCbmx6b3V2blJKUndzVkp1YXYvNzND?= =?utf-8?B?dUVtVS9ySDhvQ24wN3Z4UmFKbWw0UkczWG03bmRnQ3I5cVZZWFdIaGxqOGNl?= =?utf-8?B?YnVMQzV0Z1pmSmtJelR6aTU4bldKNURJbCsrdDFQWUFrMDh1WnI4bTR2dCtH?= =?utf-8?B?UjRIZ0xxSmZaUmszb0lEbUU1dXVTQVY1RHhCOXN6Q04rSjRIVGdiQzd3MmYy?= =?utf-8?Q?pmUTvmYcKWz3FU03iI=3D?= X-Forefront-Antispam-Report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:DM4PR11MB6502.namprd11.prod.outlook.com; PTR:; CAT:NONE; SFS:(13230040)(1800799024)(376014)(366016); DIR:OUT; SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?RGtPQUdhQVg5SmErVGs3bDRDYy8xdVpuc3NPTWZZMzBVZU9iYURnajF6Yndn?= =?utf-8?B?U0crK1pjZVNDakltamF2TFc3RXEwdERwUElsYXR6VEU1ZllyTVdWVGNtaFMx?= =?utf-8?B?R0h2Tlp6bTE3bkszQlU1TUpYMUxXbk1Td0VJc2xXeklTOE53eUJNUWFoblZV?= =?utf-8?B?bTRUZG4xNFhneWRVVGpNdUVVOVNTd0VseFRFN0E2dTF2cUx0UVM4TmRPRkVi?= =?utf-8?B?TkZDdzZ1aURLaWxndlVVeFRKeTQ4ZVlZd0RFUjE4czlnREora1p2dkR2enFD?= =?utf-8?B?TXZ2TnBZN1FLYXVIZjVuOG1tNDlwMGF1UlVuK1JBVHkrdGlLTlBocysvU3lC?= =?utf-8?B?UFBxUTByb0pnQmlGMmkxOG91THdkL3BkZEcvR3FEL0gyMXJINXNJaTJ1NU52?= =?utf-8?B?OW5XTGlvcm9HamJ6R0ZwTk10QVZEL1A4ZTBQRDhid1dEdktpQWF2YTdMWVRL?= =?utf-8?B?c1I0ZGk5VjZIOVlQOUZxcVNGbUtpS1Vnb2YybTBOc3c1Tmxxc2JkU0c4UDNB?= =?utf-8?B?bnJVbU1kdkhsWjAxKzByaXJNK0pHZStEZEhncHllQ3VYUjlUeldTcks4dFor?= =?utf-8?B?eks2SHpKSWU1LzQ0YTNkQmdHR3dnUkViSm9jaE1vVGVES0xTWVJia1pueUtQ?= =?utf-8?B?NkxMNTBvLzk1bzBtYldmenNJbEVFN0FDRGd0RmFEaXpkcFF0VjNFQnprUGpH?= =?utf-8?B?eDQwWXlYdTVqTGtFemdiNXFIZXB1eG96Uko1aks0K01HMjBXR3BUUllQYXlv?= =?utf-8?B?OElHelpCU1JwUC92U2lGMmtxWnBnQlltemFnQXA4OHVENlJ6d1VrNXRsMXQ4?= =?utf-8?B?WUVSbjgvbkc1SUxzR1Mwc2FoWmp1cGtPQU53bnpjUWpwWjJicjlCVEY5VmpR?= =?utf-8?B?S05tZTJvNWYzaHlZaWgrVFdjSHJnOURsNHpLNEFzNmJkZTRPNWw4ZTRiVWlH?= =?utf-8?B?VzdaNDNhUVdDU2RKM0phTTNhUUxTVkl5c0FNcWdZM1FrbmYzalFpeTltaWZv?= =?utf-8?B?UmlKQ1gwZ3ZPRWNGU3N3bkZLN0ZyUGJRdDFveGZTVEpvLzBaeXlIWmY1NjBn?= =?utf-8?B?YnJvVjNzOW40dWF1VGx4S1FtUW1QMDZrWEQ2eTJDdmZ4WFFUZXUwM2VjUlNL?= =?utf-8?B?Ny9xSTlOOGNwUmMxcWNxSkF5U2V6SkUzWGVUbkpEWHh6UnRDU2QxTXg2SVBV?= =?utf-8?B?Q3pPS3NqbTQvbFlRTVhFNlZqMWl0bUI5WThscG5Jc3ZFcTNMcVlCT0FhbHJQ?= =?utf-8?B?dzlPbXF5K254SkF5aHRGVnAvT200dEVYY3BpVVlRWDB3cUJiMS8rc3FjSTUr?= =?utf-8?B?WXJDWnp4OFpJQ3d5T1V0TStvc0I2UkkwYmpJWVJvRm5BUmZFMnFaaFdxQUlQ?= =?utf-8?B?aUxXWVhmcytPbkZGZkhyemEzYy9lVk4xQlFsQWQ0azZ2QkUwa0Vqb21rb0s1?= =?utf-8?B?Y3R2cmlldW1sRklzRDhIUWdEamxvRDV1RFBvalpaZWkzTHBtYmI1TDJTUTRS?= =?utf-8?B?K09JaVhqQ2tQN3JUekpuRTVXS3l5cjdoMzcxWFlLVFcwUXkyZHNsemlFam9Z?= =?utf-8?B?c1hwbytsbGRnNTBVeGlVSTUzbktFSGFzUDNuSEdFRE8vV2JzcTJuU2FueElO?= =?utf-8?B?aFROcVFoRTZJeG5nNlJ1dDEwQmRNRnlDTGI2S0U2ZWtLdjJHcHZWekxWREgz?= =?utf-8?B?bTN2eEJTM25YWGxjNDZvU2ZWNS9qd0J0bnRlUzJBUWFodVNGdFY0NzlKQkkz?= =?utf-8?B?OFRIbU5MQUZUV2Zkdnl4RkxudDhkclp5YjRud1VLVmVYUVozWFlJN2JCUCtU?= =?utf-8?B?UWN2bUJHVm5mejl2RHNpanhGL2I4RUM3U1hlUkgxcWVWWlJQaGlSM0hHVmF6?= =?utf-8?B?TVBKRmVOQ1JzOE5PTEdudG0xYTRiNGpDUGhXbm9LemY0TXo3bk9UQ2hEZGRo?= =?utf-8?B?ZmZYNXhoODF6M1JjOTZhM3BvOHFQaW9RUDdEdHRDSE5sZHplNjBBR3BYTWcw?= =?utf-8?B?NysxKzJSNnBjcU1PS2ZUazZQMnhxOHBQcTJIbXlOSkk4V2QxVnFZYnFRVWox?= =?utf-8?B?c3BVY2tsRTJxemZybkZKY0tBZW5EZ0xnWUM4UTVaTjh2cHdHY1NMdE9PNkZk?= =?utf-8?B?cGpoZ2k4MkI2VFppbFJRaWdnNHV2U2VNd1NlRFRLUFJyNnhUQWp6MW5mRHVi?= =?utf-8?B?K2c9PQ==?= X-MS-Exchange-CrossTenant-Network-Message-Id: 3d2d1f20-ea70-42d9-2d5e-08dcb0790135 X-MS-Exchange-CrossTenant-AuthSource: DM4PR11MB6502.namprd11.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 30 Jul 2024 09:21:34.1555 (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: NICiM4F9HTZ7LPalr51MelxXi8zX/KLZ55wSHHPcp23r18nMyR2a2b1Toza5tLqrmdyab0X1g2pWBz5URi6TvhOQnfMFo2pwUd4aftDI/go= X-MS-Exchange-Transport-CrossTenantHeadersStamped: SN7PR11MB6946 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 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. >> >>> >>> 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. 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? > > 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) > > >> Assuming we do that, it would actually then be possible to adjust launch >> tasks to only include *actual* built apps/examples (as well as infer things >> like platform, compiler etc.), as that's one weakness of my current "flying >> blind" approach, so I wouldn't be opposed to adding an extra step here, just >> want to make sure I understand what you're saying correctly. >> >>> >>> - On the other hand, when the build directory already exists - I think the >>> script should pull all settings from there, rather than prompting the >>> user. >>> >> >> That can be done, however, my own workflow has been that I do not ever keep >> build directories inside my source directory, so it would not be possible to >> pick up directories anywhere but the source directory. >> > > Why is that, and how does it work now, for e.g. getting the > compile_commands.json file from your build folder? Right now, at configuration time I store build directory in settings.json, and all of the other tasks (build, launch, C++ analysis) pick it up via ${config:...} variable. This is why I suggested having a notion of "active configuration" - if we just rewrite that variable, both ninja and launch tasks can be switched to a different build directory without actually having to create new tasks. More on that below, as that raises a few questions. As for why, it's a personal preference - it's annoying to have the build/ directory in my file view (it's possible to hide it, I guess I could automatically add a setting to do that in settings.json), and it interferes with e.g. source-tree-wide searches and stuff like that. This isn't a hard requirement though, I can switch to in-tree builds and automatic directory hiding if it means more automation :) > >> I also think from the point of view of the script it would be easier to >> start from known quantities rather than guess what user was trying to do >> from current configuration, but I guess a few common-sense heuristics should >> suffice for most use cases, such as e.g. inferring debug builds. >> > > What you need depends on whether you want to keep running "meson setup" - > which means you need to track all settings - or want to use "meson > configure" where you don't really need to track much at all. I guess I was aiming for the former, but doing only the latter makes sense if we assume we want to separate setup from VSCode config generation (which it seems like we're heading that way). > >>> - I'm not sure I like the idea for reconfiguring of just removing the build >>> directory and doing a whole meson setup command all over again. This >>> seems excessive and also removes the possibility of the user having made >>> changes in config to the build dir without re-running the whole config >>> script. For example, having tweaked the LTO setting, or the >>> instruction_set_isa_setting. Rather than deleting it and running meson >>> setup, it would be better to use "meson configure" to adjust the one >>> required setting and let ninja figure out how to propagate that change. >>> That saves the script from having to track all meson parameters itself. >> >> Last I checked, meson doesn't have a command that would "setup or configure >> existing" a directory, it's either "set up new one" or "configure existing >> one". I guess we could set up a fallback of "configure || setup". >> > > This goes back to the whole "create build directory after running the > script" option. If the script creates the build dir, the vscode commands > never need to use meson setup, only ever meson configure. Sure, and like I suggested above, it doesn't even have to be *this* script, it can be another, a Python-based TUI reimplementation of setup.sh :) > >>> >>> - 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. 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. > >>> >>> Final thoughts on usability: >>> >>> - Please don't write gdbsudo to /usr/local/bin without asking the user >>> first. Instead I think it should default to $HOME/.local/bin, but with a >>> prompt for the user to specify a path. >> >> It's not creating anything, it's just printing out a snippet, which, if run >> by user, would do that - the implication is obviously that the user may >> correct it if necessary. The script actually picks up path to `gdbsudo` from >> `which` command, so if the user puts their command to $HOME/.local/bin or >> something, it would get picked up if it's in PATH. I see your point about >> maybe suggesting using a home directory path instead of a system wide path, >> I can change that. > > Yep, thanks, and thanks for the explanation. > BTW: even if the user is running as non-root user, they don't always need > to use sudo (I set up my system to not need it for running DPDK). I see > there is a cmdline option for "no-gdbsudo" but I think you should make that > accessible via TUI also if non-root. Sure, all of that can be done. > > And for the cmdline parameters, how about shortening them to "--sudo" and > "--nosudo". For debug vs release builds you may want to have the latter run > without gdb at all, just with or without sudo.] I honestly never run anything outside gdb, but that's a consequence of me not really working on things that routinely require it (e.g. performace code). We can add that no problem though. > >> >>> >>> - While I realise your primary concern here is an interactive script, I'd >>> tend towards requiring a cmdline arg to run in interactive mode and >>> instead printing the help usage when run without parameters. Just a >>> personal preference on my part though. >> >> I found it to be much faster to pick my targets, apps etc. using a couple of >> interactive windows than to type out parameters I probably don't even >> remember ahead of time (especially build configurations!), and I believe >> it's more newbie-friendly that way, as I imagine very few people will want >> to learn arguments for yet-another-script just to start using VSCode. It >> would be my personal preference to leave it as default-to-TUI, but maybe >> recognizing a widely used `-i` parameter would be a good compromise for >> instant familiarity. >> > > Ok. There's always a -h option for me to get the cmdline parameters. > > I also think if the script is ok with working off an existing build > directory (or directories!), and only prompting for that, it would remove > for me the real necessity of asking for a more cmdline-fieldly version. 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) 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 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 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? [1] https://git-scm.com/docs/git-worktree -- Thanks, Anatoly