CTest: Rename PROCESSES test property to RESOURCE_GROUPS
In looking at how one might explain to people the new hardware allocation tests feature being introduced in CMake 3.16, I come up against the problem that the new
PROCESSES test property name is too close to the existing
PROCESSORS property. When said aloud, they both even sound basically the same. @purpleKarrot first raised this in the original MR, but now that I'm trying to work out how to explain it to people, I'm much more concerned that we've got the naming wrong on this one.
The feature appears to be motivated by wanting to describe how to allocate resources across multiple processes spawned by the test executable. That might be the main motivation, but I can foresee that this functionality may also make sense even for tests that don't spawn other processes. For example, it could be used to provide more fine grained resource allocation across a set of tests, such as ensuring that a set of memory-intensive tests don't consume all available memory by running too many of them in parallel, but without blocking other tests that don't use much memory and don't need to participate in the resource allocation. There are other scenarios one can up with, but hopefully the issue I'm trying to raise is clear.
I know it is getting late in the 3.16 release cycle, but I'd like to propose that we rename the
PROCESSES test property to something more aligned with resource allocation rather than processes. For the sake of discussion, I'll put forward
RESOURCE_REQUIREMENTS as a suggested alternative. We could then also rename the section in the
ctest(1) manual from
Hardware Allocation to
Resource Allocation. I'm mildly concerned that this suggested alternative name still leaves the door open for causing confusion with the
RESOURCE_LOCK property (something I already raised during the original MR), but at least the two names are distinct. We already have some documentation highlighting the relationship of this feature to
RESOURCE_LOCK, maybe we would need to give that a bit more prominence.
I have identified further minor cleanup of the docs for this feature (mostly just typos and minor inaccuracies), but I'll hold off putting up a MR for those until we resolve the above in case there are more substantial docs changes required.