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
