From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mails.dpdk.org (xvm-189-124.dc0.ghst.net [217.70.189.124]) by inbox.dpdk.org (Postfix) with ESMTP id E227DA0524; Fri, 8 Jan 2021 18:36:56 +0100 (CET) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 75EBA140EB6; Fri, 8 Jan 2021 18:36:56 +0100 (CET) Received: from mga18.intel.com (mga18.intel.com [134.134.136.126]) by mails.dpdk.org (Postfix) with ESMTP id 1F225140E85 for ; Fri, 8 Jan 2021 18:36:53 +0100 (CET) IronPort-SDR: 1/mQp4FkBZZEtR0tJet/BCfQyUW8t7kWFShUA7GxDDjlgD+PkF8S72ZCRjDARcNfReVgta3YFA Q05bp98XHtOA== X-IronPort-AV: E=McAfee;i="6000,8403,9858"; a="165315923" X-IronPort-AV: E=Sophos;i="5.79,332,1602572400"; d="scan'208";a="165315923" Received: from orsmga008.jf.intel.com ([10.7.209.65]) by orsmga106.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 08 Jan 2021 09:36:52 -0800 IronPort-SDR: jWR/LNU1mJLN8L93NEbn8nZyHIPI7R/GzjABm+Wp3w8sOaznO6JnOWa2UIo846tUzyaeLarn30 f1bHy9CN6GvQ== X-IronPort-AV: E=Sophos;i="5.79,332,1602572400"; d="scan'208";a="380189346" Received: from bricha3-mobl.ger.corp.intel.com ([10.252.4.119]) by orsmga008-auth.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-SHA; 08 Jan 2021 09:36:49 -0800 Date: Fri, 8 Jan 2021 17:36:45 +0000 From: Bruce Richardson To: Andrew Boyer Cc: Honnappa Nagarahalli , "thomas@monjalon.net" , Juraj =?utf-8?Q?Linke=C5=A1?= , Ruifeng Wang , Phil Yang , "vcchunga@amazon.com" , Dharmik Thakkar , "jerinjacobk@gmail.com" , "hemant.agrawal@nxp.com" , "Ajit Khaparde (ajit.khaparde@broadcom.com)" , "ferruh.yigit@intel.com" , "dev@dpdk.org" , bluca@debian.org, david.marchand@redhat.com, kevin.traynor@redhat.com Message-ID: <20210108173645.GD1823@bricha3-MOBL.ger.corp.intel.com> References: <1605874101-30893-1-git-send-email-juraj.linkes@pantheon.tech> <1608724059-8562-1-git-send-email-juraj.linkes@pantheon.tech> <36181A92-BE14-4E30-8F26-915AA109BB2F@pensando.io> <50293579.Yt1MtOie5U@thomas> <2B294ECB-F553-4E90-ADF3-A48692195390@pensando.io> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <2B294ECB-F553-4E90-ADF3-A48692195390@pensando.io> Subject: Re: [dpdk-dev] [PATCH v14 00/12] Arm build options rework 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 Sender: "dev" On Mon, Jan 04, 2021 at 05:46:20PM -0500, Andrew Boyer wrote: > > 1) Bruce - when the “-Ddefault_library=both” flag is passed in, the build fails with this error. It’s been broken for a long time; maybe this option isn’t supported and should be blocked earlier? > > ../../dpdk/app/meson.build:48:3: ERROR: Tried to get unknown variable "both_rte_ethdev". > Revisiting this point, since there are a number of possible approaches we can take here, and I'd like feedback on them before we do anything. Of these approaches, 2 are simple, and 1 is more complicated. 1. We can just detect this as an invalid/unsupported setting and error out earlier with a suitable errors message 2. Since we already support in all cases building "both" libraries, we can just convert "both" to be the same as "shared" for app linking (since app linking is all the value is actually used for by us) 3. We can change how we do the builds to actually repect the value as intended - only build static or shared libs as requested and only build both when value "both" is passed. Of these, #3 is obviously the most work, but may make the most sense to users. However, it does have the following open issues - which are all linked: 1. What way do we make the default linkage in the case of "both" being selected? 2. What do we make the default for builds? 3. Is there ever a case where someone needs both libraries build but non-default linkage? The initial answers I thought for these would be that the default for "both" builds should be "shared", and that "both" should be the default. However, that then is a behaviour change for DPDK since we don't get static binaries by default. The solution to that is that we change the default to "static", but then we revert to the situation we used to have with the make build where we regularly got patches upstreamed which failed to build with shared libs because the map file update was missing and the submitter never tested shared builds. The third alternative there is that we default to "both" but have "static" binaries when that is selected. That option runs against question #3 where I suspect there will be cases (e.g. packaging) where one does want both library sets generated but shared binaries. Therefore, is keeping things largely as they are and taking the simpler options #1 or #2 better? Do we want to look into #3 but with further additions such as a "default_app_linkage" DPDK option, or linking all apps twice when "both" is specified as "default_library"? Feedback welcome please. /Bruce PS: For background, when the DPDK transition to meson started, there wasn't a "both" option which is why this is not the best supported. :-)