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

[Anand Rawat]

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