From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mga06.intel.com (mga06.intel.com [134.134.136.31]) by dpdk.org (Postfix) with ESMTP id 38B242BF4 for ; Wed, 27 Mar 2019 00:13:54 +0100 (CET) X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from orsmga003.jf.intel.com ([10.7.209.27]) by orsmga104.jf.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 26 Mar 2019 16:13:52 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.60,274,1549958400"; d="scan'208";a="137525058" Received: from anandraw-mobl.amr.corp.intel.com (HELO [10.121.163.141]) ([10.121.163.141]) by orsmga003.jf.intel.com with ESMTP; 26 Mar 2019 16:13:52 -0700 To: Bruce Richardson , Jerin Jacob Kollanukkaran Cc: "pallavi.kadam@intel.com" , "thomas@monjalon.net" , "dev@dpdk.org" , "ranjit.menon@intel.com" , "jeffrey.b.shaw@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> <20190326144047.GA472084@bricha3-MOBL.ger.corp.intel.com> <87b240a5d593cde091eefce55bb64dfe1ee7533c.camel@marvell.com> <20190326164616.GA512800@bricha3-MOBL.ger.corp.intel.com> From: Anand Rawat Message-ID: <5121f16d-8011-c397-d75f-8a2db8dd3216@intel.com> Date: Tue, 26 Mar 2019 16:13:52 -0700 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.6.1 MIME-Version: 1.0 In-Reply-To: <20190326164616.GA512800@bricha3-MOBL.ger.corp.intel.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit 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 23:13:54 -0000 On 3/26/2019 9:46 AM, Bruce Richardson wrote: > On Tue, Mar 26, 2019 at 03:35:36PM +0000, Jerin Jacob Kollanukkaran wrote: >> On Tue, 2019-03-26 at 14:40 +0000, Bruce Richardson wrote: >>>> 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. >> >> I am OK with a short term hack to get Window support for DPDK, Provided >> it will be revisited before adding the next .def file. >> > Ok, some hacking has led to this as a possible approach to solve this. I've > only tested this on linux to verify it creates something approximating a > module definition file but not actually tried using it on windows. The nice > thing about meson being based on python is that we are guaranteed to have a > python3 interpreter available on whatever os we are running on. [Yes, I > made the script python2 compatible too, though I probably didn't need to!] > > I've also included in this version an (untested) override option for EAL, > to allow us to keep the .def file for EAL until we can export all the > functions listed in the map file for it. Other libraries shouldn't need > this, since they aren't as insanely big as EAL. > > /Bruce > I agree with Bruce, adding the two def files is the cleaner option and involves the least amount of changes in the common build flow. But if required shared library logic can be disabled as a part of meson workaround for windows for the initial release. -- Anand Rawat 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 499E9A05D3 for ; Wed, 27 Mar 2019 00:13:56 +0100 (CET) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id 4251E2C2F; Wed, 27 Mar 2019 00:13:55 +0100 (CET) Received: from mga06.intel.com (mga06.intel.com [134.134.136.31]) by dpdk.org (Postfix) with ESMTP id 38B242BF4 for ; Wed, 27 Mar 2019 00:13:54 +0100 (CET) X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from orsmga003.jf.intel.com ([10.7.209.27]) by orsmga104.jf.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 26 Mar 2019 16:13:52 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.60,274,1549958400"; d="scan'208";a="137525058" Received: from anandraw-mobl.amr.corp.intel.com (HELO [10.121.163.141]) ([10.121.163.141]) by orsmga003.jf.intel.com with ESMTP; 26 Mar 2019 16:13:52 -0700 To: Bruce Richardson , Jerin Jacob Kollanukkaran Cc: "pallavi.kadam@intel.com" , "thomas@monjalon.net" , "dev@dpdk.org" , "ranjit.menon@intel.com" , "jeffrey.b.shaw@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> <20190326144047.GA472084@bricha3-MOBL.ger.corp.intel.com> <87b240a5d593cde091eefce55bb64dfe1ee7533c.camel@marvell.com> <20190326164616.GA512800@bricha3-MOBL.ger.corp.intel.com> From: Anand Rawat Message-ID: <5121f16d-8011-c397-d75f-8a2db8dd3216@intel.com> Date: Tue, 26 Mar 2019 16:13:52 -0700 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.6.1 MIME-Version: 1.0 In-Reply-To: <20190326164616.GA512800@bricha3-MOBL.ger.corp.intel.com> Content-Type: text/plain; charset="UTF-8"; format="flowed" Content-Language: en-US Content-Transfer-Encoding: 7bit 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: <20190326231352.H2QRc_chfD7jxhY2yKGiUcR6Y8WxBIT7OTUulEsOhbw@z> On 3/26/2019 9:46 AM, Bruce Richardson wrote: > On Tue, Mar 26, 2019 at 03:35:36PM +0000, Jerin Jacob Kollanukkaran wrote: >> On Tue, 2019-03-26 at 14:40 +0000, Bruce Richardson wrote: >>>> 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. >> >> I am OK with a short term hack to get Window support for DPDK, Provided >> it will be revisited before adding the next .def file. >> > Ok, some hacking has led to this as a possible approach to solve this. I've > only tested this on linux to verify it creates something approximating a > module definition file but not actually tried using it on windows. The nice > thing about meson being based on python is that we are guaranteed to have a > python3 interpreter available on whatever os we are running on. [Yes, I > made the script python2 compatible too, though I probably didn't need to!] > > I've also included in this version an (untested) override option for EAL, > to allow us to keep the .def file for EAL until we can export all the > functions listed in the map file for it. Other libraries shouldn't need > this, since they aren't as insanely big as EAL. > > /Bruce > I agree with Bruce, adding the two def files is the cleaner option and involves the least amount of changes in the common build flow. But if required shared library logic can be disabled as a part of meson workaround for windows for the initial release. -- Anand Rawat