Automatic Test Sharding?

[jmerdich]

I noticed that meson will automatically run different test executables in parallel, but this doesn't do anything for independent tests within a single executable. GTest and some other competing test frameworks provide an option to 'shard' work across different process runs, essentially each doing a fraction. This would let work in a single test executable scale with the available cores.

For example, GTest honors the following environment variables:

• GTEST_TOTAL_SHARDS - Number of processes to divide the work into
• GTEST_SHARD_INDEX - Which process this invocation is
• GTEST_SHARD_STATUS_FILE - File to write to if the current exe is new enough to support sharding. This should be set to a writable-but-nonexistant path, and if the file exists it is used to indicate support for this feature.

It would be nice for Meson to be able to extend its test-driver parallelism to multiple processes-per-executable in addition to multiple exectuables-- this would drop test times for a lot of users quite nicely with minimal effort.

Things to discuss here:

• Is this something others are interested in?
• How should this be configured?
• Should this be enabled by default where it's implicitly handled by the test protocol?
• Should there be an option for test runners where it is not implicitly handled (eg, custom env var)?
• Does the test result output parsing need anything difficult to handle this feature?

[jpakkane]

The docs mentioned seem to talk mostly about running the test on multiple different machines. Meson's test runner (for the moment at least) does not really do that. It seem actually a bit strange thet you can't do something like ./your-test-exe --gtest-shard-internally. Doing the full process spawning thing seems like a fair bit of work for a single machine.

Regardless this should probably be implemented only with command line arguments to meson test rather than anything you put in meson.build files.