mbox series

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

Message ID 20210808014931.320242-1-sergey.madaminov@gmail.com
Headers show
Series use meson and ninja as a build system for ovs | expand

Message

Sergey Madaminov Aug. 8, 2021, 1:49 a.m. UTC
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@gmail.com>

Co-authored-by: William Tu <u9012063@gmail.com>
Signed-off-by: William Tu <u9012063@gmail.com>

Sergey Madaminov (1):
  moving ovs to use meson and ninja as its build system

 build-aux/copy-file-from-build.py         |  19 +
 build-aux/extract-odp-netlink-h.py        |  84 ++++
 build-aux/extract-odp-netlink-macros-h.py |  58 +++
 config.h.meson                            | 387 ++++++++++++++++++
 include/meson.build                       |  30 ++
 include/openvswitch/meson.build           |   8 +
 lib/dirs.c.in.meson                       | 113 ++++++
 lib/meson.build                           | 460 ++++++++++++++++++++++
 lib/openvswitch.map.in                    |   4 +
 lib/sflow.map.in                          |   4 +
 meson.build                               | 371 +++++++++++++++++
 meson_options.txt                         |   2 +
 ofproto/meson.build                       |  59 +++
 ofproto/ofproto.map.in                    |   4 +
 ovsdb/meson.build                         | 106 +++++
 ovsdb/ovsdb.map.in                        |   4 +
 python/ovs/meson.build                    |  24 ++
 utilities/meson.build                     |  83 ++++
 vswitchd/meson.build                      |  30 ++
 vtep/meson.build                          |  71 ++++
 vtep/vtep.map.in                          |   4 +
 21 files changed, 1925 insertions(+)
 create mode 100644 build-aux/copy-file-from-build.py
 create mode 100755 build-aux/extract-odp-netlink-h.py
 create mode 100755 build-aux/extract-odp-netlink-macros-h.py
 create mode 100644 config.h.meson
 create mode 100644 include/meson.build
 create mode 100644 include/openvswitch/meson.build
 create mode 100644 lib/dirs.c.in.meson
 create mode 100644 lib/meson.build
 create mode 100644 lib/openvswitch.map.in
 create mode 100644 lib/sflow.map.in
 create mode 100644 meson.build
 create mode 100644 meson_options.txt
 create mode 100644 ofproto/meson.build
 create mode 100644 ofproto/ofproto.map.in
 create mode 100644 ovsdb/meson.build
 create mode 100644 ovsdb/ovsdb.map.in
 create mode 100644 python/ovs/meson.build
 create mode 100644 utilities/meson.build
 create mode 100644 vswitchd/meson.build
 create mode 100644 vtep/meson.build
 create mode 100644 vtep/vtep.map.in

Comments

Ilya Maximets Aug. 9, 2021, 8:51 p.m. UTC | #1
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@gmail.com>
> 
> Co-authored-by: William Tu <u9012063@gmail.com>
> Signed-off-by: William Tu <u9012063@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.
William Tu Aug. 9, 2021, 11:59 p.m. UTC | #2
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
Van Haaren, Harry Aug. 10, 2021, 2:43 p.m. UTC | #3
> -----Original Message-----
> From: dev <ovs-dev-bounces@openvswitch.org> On Behalf Of William Tu
> Sent: Tuesday, August 10, 2021 1:00 AM
> To: Ilya Maximets <i.maximets@ovn.org>
> Cc: <dev@openvswitch.org> <dev@openvswitch.org>; Sergey Madaminov
> <sergey.madaminov@gmail.com>
> 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
> dev@openvswitch.org
> https://mail.openvswitch.org/mailman/listinfo/ovs-dev
Ilya Maximets Aug. 10, 2021, 5:46 p.m. UTC | #4
On 8/10/21 4:43 PM, Van Haaren, Harry wrote:
>> -----Original Message-----
>> From: dev <ovs-dev-bounces@openvswitch.org> On Behalf Of William Tu
>> Sent: Tuesday, August 10, 2021 1:00 AM
>> To: Ilya Maximets <i.maximets@ovn.org>
>> Cc: <dev@openvswitch.org> <dev@openvswitch.org>; Sergey Madaminov
>> <sergey.madaminov@gmail.com>
>> 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.
William Tu Aug. 13, 2021, 5:41 p.m. UTC | #5
> >>> 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