From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mga01.intel.com (mga01.intel.com [192.55.52.88]) by dpdk.org (Postfix) with ESMTP id 4E1B27CE2 for ; Tue, 26 Mar 2019 16:17:44 +0100 (CET) X-Amp-Result: UNKNOWN X-Amp-Original-Verdict: FILE UNKNOWN X-Amp-File-Uploaded: False Received: from fmsmga007.fm.intel.com ([10.253.24.52]) by fmsmga101.fm.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 26 Mar 2019 08:17:43 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.60,271,1549958400"; d="scan'208";a="137555743" Received: from bricha3-mobl.ger.corp.intel.com ([10.237.221.35]) by fmsmga007.fm.intel.com with SMTP; 26 Mar 2019 08:17:40 -0700 Received: by (sSMTP sendmail emulation); Tue, 26 Mar 2019 15:17:39 +0000 Date: Tue, 26 Mar 2019 15:17:38 +0000 From: Bruce Richardson To: Thomas Monjalon Cc: Jerin Jacob Kollanukkaran , "pallavi.kadam@intel.com" , "anand.rawat@intel.com" , "dev@dpdk.org" , "ranjit.menon@intel.com" , "jeffrey.b.shaw@intel.com" Message-ID: <20190326151738.GA488640@bricha3-MOBL.ger.corp.intel.com> References: <20190306041634.12976-1-anand.rawat@intel.com> <3620690.ieInrUnbAS@xps> <20190326144138.GB472084@bricha3-MOBL.ger.corp.intel.com> <4709724.uuJ7r4bRVe@xps> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4709724.uuJ7r4bRVe@xps> User-Agent: Mutt/1.11.2 (2019-01-07) Subject: Re: [dpdk-dev] [EXT] Re: [PATCH v5 3/8] kvargs: adding a module definition file X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Mar 2019 15:17:44 -0000 On Tue, Mar 26, 2019 at 04:07:26PM +0100, Thomas Monjalon wrote: > 26/03/2019 15:41, Bruce Richardson: > > On Tue, Mar 26, 2019 at 02:55:41PM +0100, Thomas Monjalon wrote: > > > 26/03/2019 14:37, Jerin Jacob Kollanukkaran: > > > > On Tue, 2019-03-26 at 10:58 +0000, Bruce Richardson wrote: > > > > > However, my hope is that down the road we can have the def file > > > > > generated > > > > > from the map file (or potentially vice versa). Perhaps the meson > > > > > python > > > > > module could be used to allow us to script it a bit. > > > > > > > > Make sense. Do we want to support shared lib for Windows for the first > > > > version? or Can we live with static lib till we find a proper solution. > > > > I do believe the base Windows Helloworld support needs to added this > > > > release in main repo and add the subsequent features step by step. > > > > I would treat, shared lib as subsequent feature if it is not clean. > > > > > > I agree, shared library can be supported later. > > > > > I would agree, except *not* supporting it will be more painful than what is > > proposed here. :-) > > Why? > We can just document it as broken, and test only "static" compilation. > Am I missing something? > Yes, static compilation also builds the shared libraries too. To turn that off, you'd have to modify the meson.build files to conditionally undefine the shared library builds on windows. Then undefine out the assignment to any dependency variables that are using those libraries, etc. It's doable, but it's a lot messier than adding in 2 .def files. /Bruce From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from dpdk.org (dpdk.org [92.243.14.124]) by dpdk.space (Postfix) with ESMTP id B37FCA05D3 for ; Tue, 26 Mar 2019 16:17:45 +0100 (CET) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id EB0A6D0B2; Tue, 26 Mar 2019 16:17:44 +0100 (CET) Received: from mga01.intel.com (mga01.intel.com [192.55.52.88]) by dpdk.org (Postfix) with ESMTP id 4E1B27CE2 for ; Tue, 26 Mar 2019 16:17:44 +0100 (CET) X-Amp-Result: UNKNOWN X-Amp-Original-Verdict: FILE UNKNOWN X-Amp-File-Uploaded: False Received: from fmsmga007.fm.intel.com ([10.253.24.52]) by fmsmga101.fm.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 26 Mar 2019 08:17:43 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.60,271,1549958400"; d="scan'208";a="137555743" Received: from bricha3-mobl.ger.corp.intel.com ([10.237.221.35]) by fmsmga007.fm.intel.com with SMTP; 26 Mar 2019 08:17:40 -0700 Received: by (sSMTP sendmail emulation); Tue, 26 Mar 2019 15:17:39 +0000 Date: Tue, 26 Mar 2019 15:17:38 +0000 From: Bruce Richardson To: Thomas Monjalon Cc: Jerin Jacob Kollanukkaran , "pallavi.kadam@intel.com" , "anand.rawat@intel.com" , "dev@dpdk.org" , "ranjit.menon@intel.com" , "jeffrey.b.shaw@intel.com" Message-ID: <20190326151738.GA488640@bricha3-MOBL.ger.corp.intel.com> References: <20190306041634.12976-1-anand.rawat@intel.com> <3620690.ieInrUnbAS@xps> <20190326144138.GB472084@bricha3-MOBL.ger.corp.intel.com> <4709724.uuJ7r4bRVe@xps> MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Disposition: inline In-Reply-To: <4709724.uuJ7r4bRVe@xps> User-Agent: Mutt/1.11.2 (2019-01-07) Subject: Re: [dpdk-dev] [EXT] Re: [PATCH v5 3/8] kvargs: adding a module definition file X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 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" Message-ID: <20190326151738.TBQKEvolm_oftiVkqTMwQJ80ZFLzYaj4VVL7pY6XPAY@z> On Tue, Mar 26, 2019 at 04:07:26PM +0100, Thomas Monjalon wrote: > 26/03/2019 15:41, Bruce Richardson: > > On Tue, Mar 26, 2019 at 02:55:41PM +0100, Thomas Monjalon wrote: > > > 26/03/2019 14:37, Jerin Jacob Kollanukkaran: > > > > On Tue, 2019-03-26 at 10:58 +0000, Bruce Richardson wrote: > > > > > However, my hope is that down the road we can have the def file > > > > > generated > > > > > from the map file (or potentially vice versa). Perhaps the meson > > > > > python > > > > > module could be used to allow us to script it a bit. > > > > > > > > Make sense. Do we want to support shared lib for Windows for the first > > > > version? or Can we live with static lib till we find a proper solution. > > > > I do believe the base Windows Helloworld support needs to added this > > > > release in main repo and add the subsequent features step by step. > > > > I would treat, shared lib as subsequent feature if it is not clean. > > > > > > I agree, shared library can be supported later. > > > > > I would agree, except *not* supporting it will be more painful than what is > > proposed here. :-) > > Why? > We can just document it as broken, and test only "static" compilation. > Am I missing something? > Yes, static compilation also builds the shared libraries too. To turn that off, you'd have to modify the meson.build files to conditionally undefine the shared library builds on windows. Then undefine out the assignment to any dependency variables that are using those libraries, etc. It's doable, but it's a lot messier than adding in 2 .def files. /Bruce