Re: [dpdk-dev] [EXT] Re: [PATCH v5 3/8] kvargs: adding a module definition file

[Bruce Richardson <bruce.richardson@intel.com>]

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 <bruce.richardson@intel.com>
> > > > Signed-off-by: Anand Rawat <anand.rawat@intel.com>
> > > > Reviewed-by: Pallavi Kadam <pallavi.kadam@intel.com>
> > > > Reviewed-by: Ranjit Menon <ranjit.menon@intel.com>
> > > > ---
> > > >  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