Support system tests with pseudo CMake targets

Merge request !124 (merged) (and !125 (merged)) broke support for using pseudo CMake targets in dune_add_system_tests which we were relying on in dorie, see dorie#161 and dorie!165.

Overview

The CMake function dune_add_system_tests requires either TARGET or SOURCE as arguments (by the way, this is not documented in the function docstring), meaning that either an existing target is used for the test or the function creates one or multiple new targets from the specified sources. The respective target is then passed to the Python wrapper script as --exec argument. MR !124 (merged) now imposes new restrictions on the TARGET: It must have a TARGET_FILE, or some sort of location. A target defined by add_custom_target or INTERFACE libraries do not have this property.

Our use case

In DORiE, we compile multiple executable targets and combine them via a custom target dorie, such that the command make dorie compiles all of them. We use a Python wrapper for executing the proper executable and running the tests based on the configuration files it receives. Before the !124 (merged) "bugfix", we could use the dorie pseudo target as argument to TARGET in dune_add_system_tests. Its name was used as basename for the tests and passed via the --exec argument to our wrapper which never evaluated it. This is now not possible anymore. Instead, we have to define a dummy target with an arbitrary location to make sure CMake can query TARGET_FILE_DIR and TARGET_FILE_NAME.

Proposal

Custom Python wrapper scripts handed over to dune_add_system_tests via the SCRIPT variable might not require a target location for executing the test. Therefore:

• Make the TARGET variable optional if a custom SCRIPT is passed to the function.
• If TARGET is not defined, do not pass an --exec argument to the script.
• If TARGET is not defined, require a BASENAME argument for naming the tests.