In preparation for adding big-endian tests, disable them on macOS
where many are failing, although it looks like the cause of failure
may not relate to endian conversion, it needs further investigation.
These are really basic testing as well, merely linking or appending the
first collection or object in all processed blendfiles. But it should
help catching 'rare' issues in linking/appending from older blendfiles.
The `io_blendfile_versioning` test is currently one of the slowest
(excluding Cycles ones) in debug builds, it can easily take several
minutes to complete.
This commit split it into several instances, each processing a subset of
all the blendfiles.
This gives a strong speed-up when only running that specific test.
As expected, speedup is neglectable when running the whole test suite
though.
| instances | debug | release | debug all* | release all |
| --------- | ------ | ------- | ---------- | ----------- |
| 1 | 190.95 | 19.39 | 439.54 | 63.51 |
| 4 | 61.80 | 6.81 | N/A | N/A |
| 8 | 38.33 | 5.14 | 435.00 | 58.93 |
| 16 | 33.97 | 4.16 | N/A | N/A |
| 32 | 46.54 | 5.14 | N/A | N/A |
Times are in seconds.
`instances` are the number of tests generated (1 is same as before this
commit).
The first two columns are timings for running the versioning test only,
the last two are timings for the full test suite (excluding Cycles tests
in the debug build case).
This is fairly brute force and rough, but there are quite a few old
files in there, helps a bit with versioning and readfile code testing.
Note: Five files are currently excluded since failing in debug builds
at least, most of the time for memleaks issues. The two other 'errors'
may also not be actual issues, but this needs to be investigated further.
Also, in the future, when time allows, it may be better to generate a
set of dedicated testing files, with as many official releases versions
as possible?
Re. #112649.
