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 AFCF3A04B5; Mon, 11 Jan 2021 10:38:16 +0100 (CET) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 2B762140CB8; Mon, 11 Jan 2021 10:38:16 +0100 (CET) Received: from new1-smtp.messagingengine.com (new1-smtp.messagingengine.com [66.111.4.221]) by mails.dpdk.org (Postfix) with ESMTP id 8A88F140CAF for ; Mon, 11 Jan 2021 10:38:14 +0100 (CET) Received: from compute2.internal (compute2.nyi.internal [10.202.2.42]) by mailnew.nyi.internal (Postfix) with ESMTP id C0A9C580567; Mon, 11 Jan 2021 04:38:13 -0500 (EST) Received: from mailfrontend1 ([10.202.2.162]) by compute2.internal (MEProxy); Mon, 11 Jan 2021 04:38:13 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=monjalon.net; h= from:to:cc:subject:date:message-id:in-reply-to:references :mime-version:content-transfer-encoding:content-type; s=fm3; bh= kBYmrzEPTKLXJWIXEAmhfuddYDMFadsd32N84s/t3Pw=; b=AIqbDxVMdWOi9gS9 k9ZQsn6/XDpKloNAAiixBJSsJqlIL1wgjSJuov3kL2Rs5GufbWH2FrZ9n39wJlt7 zNwlrVus7+OUs0ZSIB9HjAIro2nogEpFxBnVd6eU7da6Mgw6+cEU0F5Uworid+kQ t1oLY/pK3xOcXtqfvA9KmRDMCYo2TF/f00G0GPoXQrZF/6EGgKTZJEIzkyhdjax6 P3WJri7ipAR64+NET3RCPV21/2bUkwJlgUF+PIA6729y080Wyz70UEz2odxpK5t+ YFIApU9uORCbC3cfUmUop9qLJ+Fpr8xRKaaylWiRWLDUTw70zrvONTPSoc7IXp3r R7bMeQ== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender :x-sasl-enc; s=fm1; bh=kBYmrzEPTKLXJWIXEAmhfuddYDMFadsd32N84s/t3 Pw=; b=ckrAigI9fvwmm453rZ7FsGkmuafRGPGSkZuGq99F47g/2NE/fMA+6aG2Z V8ZgXqjYWA9Lfvr7AltnTY1cXphlWWzIDlBBBZ1gISzDLjqcm8dSYo0g8iUR5F+/ MqBWPqXxOcEgVPhmTay9ApofuUEvXpIS9ltV6nYvtfypSW/RJabhcaiJcGd+w3qn M8tFs223WL1t//rCukSnd6BqlSFNmdO4WMDXvh1tiLdHSOnw3fFUTUFCfCk1OXBJ j01CNx6DoQGxD+Lp2JfJjsfEJXdn82ZeYfyIkS3NVE2hSzGZ58BHxVHUsyh7eJm7 NxU4u5/uk03j+DSJd+6RHKX4ZW0EA== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedujedrvdehuddgtdeiucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhephffvufffkfgjfhgggfgtsehtqhertddttdejnecuhfhrohhmpefvhhhomhgr shcuofhonhhjrghlohhnuceothhhohhmrghssehmohhnjhgrlhhonhdrnhgvtheqnecugg ftrfgrthhtvghrnhepkeethedtieevhfeigeejleegudefjeehkeekteeuveeiuedvveeu tdejveehveetnecukfhppeejjedrudefgedrvddtfedrudekgeenucevlhhushhtvghruf hiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpehthhhomhgrshesmhhonhhjrghl ohhnrdhnvght X-ME-Proxy: Received: from xps.localnet (184.203.134.77.rev.sfr.net [77.134.203.184]) by mail.messagingengine.com (Postfix) with ESMTPA id E9E2A240062; Mon, 11 Jan 2021 04:38:09 -0500 (EST) From: Thomas Monjalon To: Bruce Richardson , Honnappa Nagarahalli Cc: Andrew Boyer , Juraj =?utf-8?B?TGlua2XFoQ==?= , 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" Date: Mon, 11 Jan 2021 10:38:09 +0100 Message-ID: <26840311.mCdcc087Xs@thomas> In-Reply-To: References: <1605874101-30893-1-git-send-email-juraj.linkes@pantheon.tech> <20210108173645.GD1823@bricha3-MOBL.ger.corp.intel.com> MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="UTF-8" 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" 08/01/2021 21:20, Honnappa Nagarahalli: > > On Mon, Jan 04, 2021 at 05:46:20PM -0500, Andrew Boyer wrote: > > > > > > 1) Bruce - when the =E2=80=9C-Ddefault_library=3Dboth=E2=80=9D flag = is passed in, the build > > fails with this error. It=E2=80=99s been broken for a long time; maybe = this option isn=E2=80=99t > > 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. > >=20 > > 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 a= ll cases >=20 > I would prefer option 1 here (detect and error out). IMO, the option "bot= h" does not seem to solve a compelling problem. I would prefer to avoid the= additional code and complications. Mostly, everyone would do the developme= nt with either 'static' or 'shared' and test the other at the end when the = development is completed. +1 for not supporting linking with both. > > 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 actuall= y used for > I do not think option 2 solves the problem completely. i.e. if the user s= pecifies 'both', app needs to be built for both static and shared libraries. >=20 > > by us) 3. We can change how we do the builds to actually repect the val= ue as > > intended - only build static or shared libs as requested and only build= both > > when value "both" is passed. > >=20 > > 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 no= n- > > default linkage? > >=20 > > 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 st= atic > > 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 w= ith > > shared libs because the map file update was missing and the submitter n= ever > > tested shared builds. >=20 > I have been one among submitting the patches without testing for shared l= ibraries. But, I am thinking that we have a good CI now that compiles for v= arious combinations. I think that should be enough. >=20 > > The third alternative there is that we default to "both" > > but have "static" binaries when that is selected. That option runs agai= nst > > question #3 where I suspect there will be cases (e.g. > > packaging) where one does want both library sets generated but shared > > binaries. > >=20 > > 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"? >=20 > I would say stick with #1 as there is not a compelling problem to solve. me too And I want to avoid linking static apps by default because they are huge.