On 8/10/21 4:43 PM, Van Haaren, Harry wrote: >> -----Original Message----- >> From: dev <[email protected]> On Behalf Of William Tu >> Sent: Tuesday, August 10, 2021 1:00 AM >> To: Ilya Maximets <[email protected]> >> Cc: <[email protected]> <[email protected]>; Sergey Madaminov >> <[email protected]> >> Subject: Re: [ovs-dev] [PATCH RFC 0/1] use meson and ninja as a build system >> for ovs >> >> Hi Ilya, >> >> Thanks for your feedback! >> >>> Hi, Sergey and William. Thanks for working on this. > > Hey All, > > Nice RFC! Re cloning from github & running meson commands, I had to run > the following as the file isn't renamed in upstream commit (for future > readers): > $ git mv lib/dirs.c.in lib/dirs.c.in.meson > > I manually decreased the required Meson version, all compiled fine after that! > > >>> I think that it might be a good idea to move to a different build system >>> that will not be that painful to run on Windows. I'm not working on >>> Windows parts, but it would be great to have a fast CI that can confirm >>> that everything still working fine. >> >> Yes, and avoiding the msys/mingw makes coding and debugging on windows >> much easier. > > Generally +1 for Meson from me, my DPDK experience has been positive, as > has Meson for various smaller open source projects I've worked on. > > I'm happy to contribute to the Meson build-system enabling as far as the > CPU-ISA > enabling/AVX512 library code goes - although I think Sergey has a (commented) > implementation of the "openvswitchavx512" library in the RFC patchset. > > > >>> However, as I already said in the discussion on GitHub, it seems to be >>> very hard to migrate our testsuite that heavily depends on autotest. >>> And without migrating the testsuite we will, probably, have to maintain >>> two different build systems to be able to run tests. This, kind of, >>> defeats the whole purpose of the change. >> >> Why is it very hard? >> I thought once we find a way to add tests to meson, it's just >> "mechanically" copying all these scripts into a new test framework. >> It's a lot of tedious work, but hopefully not a difficult or impossible task. >> >> Or does current OVS autotests heavily depend on autotool/autoconf? >> I see the test cases are pretty independent. > > I'm not very familiar with the tests, but today the AT_CHECK() syntax used to > write the tests is pretty autotools specific.
Yep. The way how it works is that Autoconf takes the whole bunch of ./tests/*.at files and generates a giant shell script ./tests/testsuite out of them by replacing all the AT_CHECK/AT_SETUP/AT_DATA/AT_WHATEVER with a corresponding shell code snippet, adds a bunch of a system environment checks and defines, performs substitution of all the user-defined macros and creates shell functions out of user-defined functions. Basically, that is what we will need to re-implement as meson doesn't provide replacement for most of these things. We will, probably, need to make every test a separate shell script or make a giant script that can run one requested test, and maybe, create a library of helper scripts to avoid massive code duplication. Another point is that if these are still shell scripts, we still need msys2 or whatever to run a shell, right? > Agree that in theory running the > commands from different test runner infrastructure shouldn't be an issue. I agree that once we have a test framework it should be just a matter of time to migrate all the tests. The problem is that I'm afraid we will have to create one as the test framework in meson is just a way to run a single binary/script, but it doesn't provide any instruments to actually write these binaries/scripts. > > As I'm not familiar as others here, I'll just be quiet on the topic :) > > >>> Meson is a nice system in many aspects, but its support for tests is very >>> limited. IIUC, it can only run a single binary and check the error codes. >>> Most of our tests starts several daemons and performs several fairly complex >>> operations and checks. I'm afraid that we will end up writing our own >>> separate testing framework that will mimic autotest in order to be able to >>> run our tests from meson. >>> >>> Did you think about this problem? Do you have a solution in mind? >> >> Thanks, we thought about it but I don't have a solution in mind at this >> moment. PoC of the build process is fine and I had no doubts that it can be done. I'd suggest to make a PoC for at least one unit test that we have (e.g. "ofproto-dpif - MPLS handling with goto_table") or two tests to actually figure out what we need to do with them. Best regards, Ilya Maximets. _______________________________________________ dev mailing list [email protected] https://mail.openvswitch.org/mailman/listinfo/ovs-dev
