Adds catch2.hpp and a minimal framework to do unit testing on interp. If this gets general approval, I have some additional unit tests based on this to backport from another branch. Currently the unit test build is implemented in Meson as a parallel build system.
评论 (5)
#2 – robEllenberg 于 2019-06-28
@sebastiankuzminsky Great question! It seems like an odd choice, I know, but it was both because of my frustration with the current build system, and curiosity about meson as the up-and-coming “build system of the future”. I did a parallel build system to avoid risking disruption to the existing kernel-space builds. The unit tests have minimal dependencies, and are only a few files each of actual code, so it was a good toy problem to try a new build system for. In the future, it could grow to be the main build for LinuxCNC (like various gnome projects have done), or we could migrate it all to CMake. Porting from Meson to CMake (especially for a small build) is probably easier than the equivalent port from autotools, too.
As for why I chose Meson vs other options, I wanted to get some experience with it and see if the claims were true. So far, I’ve been impressed with it. It’s easy to diagnose and add missing dependencies, and it has useful intermediate structures (e.g. file name / include path containers that remember the full path, dependency definitions as an object). The syntax that is intuitive (at least for a python user). I’m not yet sure how well it will scale, but it’s been fast and robust so far. Dependencies are easy to manage too because it requires all source files to be explicitly defined in the build files. This is in theory more painful than globbing sources with Make, but it’s very good about not making you repeat yourself. A properly-laid-out dependency tree only needs one mention of a source file name, for example.
#3 – robEllenberg 于 2019-07-03
@mozmck Agreed, multi-spindle unit tests would be a great exercise for anyone interested in trying out the unit test framework. I still need to document how to create a unit test, and use the helper utilities, since there’s a bunch of under-the-hood stuff that’s necessary to make them run smoothly. For now, an enterprising developer could copy one of the existing tests and tweak it to their purposes.
I’ll have more documentation and some improvements (tests for emccanon, interp stack trace printing), but that will take a few calendar weeks to clean up and rebase.
@andypugh Are you interested in taking a stab at multi-spindle tests? if so, it would be great to get feedback on the framework, and I can patch up any gaps you run into.
#4 – andypugh 于 2019-07-03
I am a bit busy right now.
How do these tests differ from the existing tests?
#5 – robEllenberg 于 2019-07-03
They’re based in Catch, which is a powerful unit test framework. It’s not a replacement for runtest, but the unit tests are much easier to write due to the variety of assert conditions and helper macros.
#1 – sebastiankuzminsky 于 2019-06-28
Why are you adding a parallel build system?