From mboxrd@z Thu Jan 1 00:00:00 1970 From: Bruce Richardson Subject: Re: [EXT] Re: [PATCH v5 3/8] kvargs: adding a module definition file Date: Tue, 26 Mar 2019 14:40:47 +0000 Message-ID: <20190326144047.GA472084@bricha3-MOBL.ger.corp.intel.com> References: <20190306041634.12976-1-anand.rawat@intel.com> <20190326060238.9884-1-anand.rawat@intel.com> <20190326060238.9884-4-anand.rawat@intel.com> <13f7c718448539712a6ba5024959b296143555e6.camel@marvell.com> <20190326105831.GA188340@bricha3-MOBL.ger.corp.intel.com> <5eeb911a2c8a3877f5ae110b88f56ba76df642de.camel@marvell.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: "pallavi.kadam@intel.com" , "thomas@monjalon.net" , "anand.rawat@intel.com" , "dev@dpdk.org" , "ranjit.menon@intel.com" , "jeffrey.b.shaw@intel.com" To: Jerin Jacob Kollanukkaran Return-path: Received: from mga04.intel.com (mga04.intel.com [192.55.52.120]) by dpdk.org (Postfix) with ESMTP id B6F025B1C for ; Tue, 26 Mar 2019 15:40:56 +0100 (CET) Content-Disposition: inline In-Reply-To: <5eeb911a2c8a3877f5ae110b88f56ba76df642de.camel@marvell.com> 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 Tue, Mar 26, 2019 at 01:37:33PM +0000, Jerin Jacob Kollanukkaran wrote: > On Tue, 2019-03-26 at 10:58 +0000, Bruce Richardson wrote: > > ------------------------------------------------------------------- > > --- > > On Tue, Mar 26, 2019 at 10:32:34AM +0000, Jerin Jacob Kollanukkaran > > wrote: > > > On Mon, 2019-03-25 at 23:02 -0700, Anand Rawat wrote: > > > > adding a DEF file for kvargs to specify the exports > > > > for the creation of the shared library. > > > > > > > > Signed-off-by: Bruce Richardson > > > > Signed-off-by: Anand Rawat > > > > Reviewed-by: Pallavi Kadam > > > > Reviewed-by: Ranjit Menon > > > > --- > > > > lib/librte_kvargs/rte_kvargs_exports.def | 7 +++++++ > > > > 1 file changed, 7 insertions(+) > > > > create mode 100644 lib/librte_kvargs/rte_kvargs_exports.def > > > > > > > > diff --git a/lib/librte_kvargs/rte_kvargs_exports.def > > > > b/lib/librte_kvargs/rte_kvargs_exports.def > > > > new file mode 100644 > > > > index 000000000..265d3cc9a > > > > --- /dev/null > > > > +++ b/lib/librte_kvargs/rte_kvargs_exports.def > > > > > > Maintaining two separate files (.map and .def) for shared > > > library definition will be pain full. > > > > > > > Yes, though I'd question how much more painful it is than having to > > update > > a separate map file anyway - just consider the number of patches that > > It is painful due to the fact that, If it is windows ONLY file then > developer need to test on Windows as well as it may break Windows. > If it is a common file, at least, it will be tested on one platform. > So responsibly wise it is a clean partition between windows eal > maintainers vs generic library maintainers. > Yes, good point. However, once we get some windows support into the main repo then there is the requirement not to break that, so some testing on windows before merge will prove necessary. Hopefully that can be done just via CI, rather than having maintainers/committers do so manually. > > have been submitted over the years which failed shared library build > > because map file updates were forgotten. > > > > 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. > Yes, I did consider that possibility. However, turning off shared builds for windows is more of a hack than adding a definition file, since it involves more (temporary) changes to the meson.build for both lib and driver. If I get the chance, I'll see how complicated it might be to autogenerate them at build. Otherwise, I'd suggest keeping the .def files for now, since only 2 libraries are involved, but then we need to come up with a proper solution before the number of libraries compiled on windows goes above that initial 2. /Bruce