[ovs-dev] [PATCH RFC 0/1] use meson and ninja as a build system for ovs

[Ilya Maximets]

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: 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 <PATH_TO_UPSTREAM_OVS>`
> 
> On Windows:
> -----------
> 
> 1. Install the prerequisites listed in the OvS for Windows documentation [7]
> 2. Open the Visual Studio Developer CLI, Powershell, or Command Prompt
> 3. Clone OvS with meson build system from this repository: https://github.com/smadaminov/ovs-dpdk-meson
> 4. Enter the 'ovs' folder in the cloned repository
> 5. Set Clang as a compiler: `set CC=clang`
> 6. Run meson configuration: `meson build -Dwith-pthread=<PATH_TO_PTHREADS4W>`
> 7. Build OvS: `ninja -C build`
> 
> --- References
> 
> [1] https://www.youtube.com/watch?v=KF9KKPXfAzM
>    - http://patchwork.ozlabs.org/project/openvswitch/patch/20200902180629.29573-1-sunil.pai.g@intel.com/
>    - http://patchwork.ozlabs.org/project/openvswitch/patch/20201111113401.66709-1-sunil.pai.g@intel.com/
> [2] https://mesonbuild.com/Simple-comparison.html
> [3] https://mesonbuild.com/Porting-from-autotools.html
> [4] https://mesonbuild.com/Comparisons.html
> [5] https://inbox.dpdk.org/users/2129484.qSt5SVLHR2@thomas/T/
> [6] https://mesonbuild.com/Getting-meson.html
> [7] https://docs.openvswitch.org/en/latest/intro/install/windows/#build-requirements
> 
> Signed-off-by: Sergey Madaminov <sergey.madaminov at gmail.com>
> 
> Co-authored-by: William Tu <u9012063 at gmail.com>
> Signed-off-by: William Tu <u9012063 at gmail.com>

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.

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.

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?

Best regards, Ilya Maximets.