Re: [ovs-dev] [PATCH RFC 0/1] use meson and ninja as a build system for ovs
> >>> 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. > Thanks! That makes sense. Sergey is looking for two possible solutions: Avocado testing framework https://avocado-framework.readthedocs.io/en/90.0/quickstart/index.html or Unity test framework https://docs.unity3d.com/Packages/com.unity.test-framework@1.1/manual/index.html or any suggestions are welcome! Regards, William ___ dev mailing list d...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-dev
Re: [ovs-dev] [PATCH RFC 0/1] use meson and ninja as a build system for ovs
On 8/10/21 4:43 PM, Van Haaren, Harry wrote: >> -Original Message- >> From: dev On Behalf Of William Tu >> Sent: Tuesday, August 10, 2021 1:00 AM >> To: Ilya Maximets >> Cc: ; Sergey Madaminov >> >> 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 d...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-dev
Re: [ovs-dev] [PATCH RFC 0/1] use meson and ninja as a build system for ovs
> -Original Message- > From: dev On Behalf Of William Tu > Sent: Tuesday, August 10, 2021 1:00 AM > To: Ilya Maximets > Cc: ; Sergey Madaminov > > 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. Agree that in theory running the commands from different test runner infrastructure shouldn't be an issue. 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. > > Regards, > William > ___ > dev mailing list > d...@openvswitch.org > https://mail.openvswitch.org/mailman/listinfo/ovs-dev ___ dev mailing list d...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-dev
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. > > 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. > > 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. > > 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. Regards, William ___ dev mailing list d...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-dev
Re: [ovs-dev] [PATCH RFC 0/1] use meson and ninja as a build system for ovs
On 8/8/21 3:49 AM, Sergey Madaminov wrote: > This RFC proposes to replace current, autotools-based, build system with > meson. > It won't break the current build system process, which will allow for a > gradual transition. > Furthermore, the new build system will natively work across multiple > operating systems (now it compiles on both Windows and Linux). > As OVS build process relies on shell scripts to generate C source codes, > ex: lib/dirs.c.in, we re-written them in Python to make them portable (as > awk/sed works differently on Windows platform). > This does not introduce new dependencies (besides installing meson and ninja) > as Python is already being actively used to generate some of the files. > > Multiple projects use meson as their build system where they replaced > autotools or make files. > For example, QEMU, libvirt, and DPDK [1] already use it. > It helps to speed up configuration and compilation process [2]. > Additionally, meson build files have a more centralized logic. > Thus, it is not scattered across multiple files, e.g., configure.ac, > Makefile.am, and acinclude.m4. > And meson.build files are easier to write, comprehend, and debug. > So it will lower the entry barriers for the newcomers. > > Currently, we are able to compile OvS on both Windows and Linux using Clang > and meson with ninja backend. > While we have not yet implemented building several parts including AF_XPD, > AVX, and Documentation, all necessary binaries are generated. > > Motivation > ** > > Using autotools to build OvS on Linux works great. > However, they are not natively available on Windows and require emulated > shell, ex: msys2 or mingw, to use them. > This results in having additional dependency and significantly slows down > build process. > We tested running "./boot.sh && ./configure && make" on Windows and it takes > >5min. > Furthermore, it introduces an additional layer of indirection, which makes it > harder to debug build related issues. > Having that additional layer not only slows down the build process but also > introduce additional dependencies, e.g., msys2 and mingw with potentially > their own limitations and issues. > And this approach also requires a constant maintenance of build-aux/cccl > wrapper for cl.exe and link.exe. > > Another downside of autotools is that it has a relatively high entry barrier. > It is not straightforward how to read and write them. > And debugging issues in a build process is quite painful. > > Instead of trying to find a workaround, projects such as DPDK adopted a new > build system called meson written in Python. > And it works natively on both Linux and Windows operating systems. > As OvS and DPDK projects are closely related, we decided to explore that > option as well given the fact that OvS supports Clang on both platforms. > Our experience showed that writing and reading meson.build files is quite > simple. > And they also have a helpful document to ease transition from autotools [3]. > > Why Meson? > ** > > As the main driver to transition to a new build system was to ease a build > process on Windows, there were several other candidates for a new build > system. > > Bazel > - > > This is another emerging build system that gains traction. > However, it seems that there could be potential issues of using Bazed on > Windows [4]. > And DPDK does not look forward to add Bazel support [5]. > > CMake > - > > It is well integrated with Visual Studio, which is a plus. > Additionally, it is a quite mature build system with many features. > However, CMake files are not particularly easy to read and write and it also > does things under the hood. > It makes it potentially problematic to debug build process. > > Visual Studio Solutions > --- > > While this sounds like a good approach at first, it would work only on > Windows. > This means that it would require a separate effort to develop and maintain > such approach. > > Given the above, I chose meson with ninja backend for the following reasons: > > (1) Native runs on both Linux and Windows and does not introduce additional > dependency as it only requires Python [6], which is already required by OvS > (2) Does not require a significant separate effort to maintain it for > different operating systems > (3) Fast build process > (4) DPDK uses meson and it is a closely replated project so it would make > sense to have the same build system > > Usage Instruction > * > > On Linux: > - > > 1. Clone OvS with meson build system from this repository: > https://github.com/smadaminov/ovs-dpdk-meson > 2. Enter the 'ovs' folder in the cloned repository > 3. Run meson configuration step: `meson build` >- To set Clang as a compiler: `CC=clang meson build` > 4. Build OvS: `ninja -C build` > > Additionally, you can clone current OvS master branch (as of this writing > commit hash:
[ovs-dev] [PATCH RFC 0/1] use meson and ninja as a build system for ovs
This RFC proposes to replace current, autotools-based, build system with meson. It won't break the current build system process, which will allow for a gradual transition. Furthermore, the new build system will natively work across multiple operating systems (now it compiles on both Windows and Linux). As OVS build process relies on shell scripts to generate C source codes, ex: lib/dirs.c.in, we re-written them in Python to make them portable (as awk/sed works differently on Windows platform). This does not introduce new dependencies (besides installing meson and ninja) as Python is already being actively used to generate some of the files. Multiple projects use meson as their build system where they replaced autotools or make files. For example, QEMU, libvirt, and DPDK [1] already use it. It helps to speed up configuration and compilation process [2]. Additionally, meson build files have a more centralized logic. Thus, it is not scattered across multiple files, e.g., configure.ac, Makefile.am, and acinclude.m4. And meson.build files are easier to write, comprehend, and debug. So it will lower the entry barriers for the newcomers. Currently, we are able to compile OvS on both Windows and Linux using Clang and meson with ninja backend. While we have not yet implemented building several parts including AF_XPD, AVX, and Documentation, all necessary binaries are generated. Motivation ** Using autotools to build OvS on Linux works great. However, they are not natively available on Windows and require emulated shell, ex: msys2 or mingw, to use them. This results in having additional dependency and significantly slows down build process. We tested running "./boot.sh && ./configure && make" on Windows and it takes >5min. Furthermore, it introduces an additional layer of indirection, which makes it harder to debug build related issues. Having that additional layer not only slows down the build process but also introduce additional dependencies, e.g., msys2 and mingw with potentially their own limitations and issues. And this approach also requires a constant maintenance of build-aux/cccl wrapper for cl.exe and link.exe. Another downside of autotools is that it has a relatively high entry barrier. It is not straightforward how to read and write them. And debugging issues in a build process is quite painful. Instead of trying to find a workaround, projects such as DPDK adopted a new build system called meson written in Python. And it works natively on both Linux and Windows operating systems. As OvS and DPDK projects are closely related, we decided to explore that option as well given the fact that OvS supports Clang on both platforms. Our experience showed that writing and reading meson.build files is quite simple. And they also have a helpful document to ease transition from autotools [3]. Why Meson? ** As the main driver to transition to a new build system was to ease a build process on Windows, there were several other candidates for a new build system. Bazel - This is another emerging build system that gains traction. However, it seems that there could be potential issues of using Bazed on Windows [4]. And DPDK does not look forward to add Bazel support [5]. CMake - It is well integrated with Visual Studio, which is a plus. Additionally, it is a quite mature build system with many features. However, CMake files are not particularly easy to read and write and it also does things under the hood. It makes it potentially problematic to debug build process. Visual Studio Solutions --- While this sounds like a good approach at first, it would work only on Windows. This means that it would require a separate effort to develop and maintain such approach. Given the above, I chose meson with ninja backend for the following reasons: (1) Native runs on both Linux and Windows and does not introduce additional dependency as it only requires Python [6], which is already required by OvS (2) Does not require a significant separate effort to maintain it for different operating systems (3) Fast build process (4) DPDK uses meson and it is a closely replated project so it would make sense to have the same build system Usage Instruction * On Linux: - 1. Clone OvS with meson build system from this repository: https://github.com/smadaminov/ovs-dpdk-meson 2. Enter the 'ovs' folder in the cloned repository 3. Run meson configuration step: `meson build` - To set Clang as a compiler: `CC=clang meson build` 4. Build OvS: `ninja -C build` Additionally, you can clone current OvS master branch (as of this writing commit hash: 765c8a774dfebea9ec78c20a3de5e89703d0a3a0) and use the `copy_files.sh` script to copy files related to the new meson build. Run the script from the folder where it is located and provide the path to the upstream OvS as its argument: `bash copy_files.sh ` On Windows: --- 1. Install the
