From a comment in #207:
It used to be that TEST_RM was a only build-time flag that just determined which test_driver_${TEST_RM} file got copied to test_driver_rm installation location. And we could switch RMs (I'd usually switch between serial and the system RM) by manually copying a different file to the installation location. Now we have to switch RMs with two steps that have to agree: Update TEST_RM in runTests and copy the desired file.
Let's fix this in another PR. But let's get back to needing to change only one thing to switch RMs. My suggestion is to:
- Stop using TEST_RM at build time to determine which test_driver_${TEST_RM} file to install. Instead install all files.
- Start using TEST_RM at test runtime to select which of the many test_driver_{TEST_RM} to execute.
- Add a flag to runTests letting the user pick which RM to use.
- Add a config setting the default value TEST_RM. Perhaps we could grep that out of the config file, since the testsuite doesn't have access to the normal config parser.
This will also improve our ability to have a system-independent build that could be part of a spack binary cache.
From a comment in #207:
It used to be that TEST_RM was a only build-time flag that just determined which test_driver_${TEST_RM} file got copied to test_driver_rm installation location. And we could switch RMs (I'd usually switch between serial and the system RM) by manually copying a different file to the installation location. Now we have to switch RMs with two steps that have to agree: Update TEST_RM in runTests and copy the desired file.
Let's fix this in another PR. But let's get back to needing to change only one thing to switch RMs. My suggestion is to:
This will also improve our ability to have a system-independent build that could be part of a spack binary cache.