Cygwin executables are still loaded by the Windows PE loader, so PATH needs
to include any extra directories where required DLLs can be found.
Cygwin uses a unix style ':'-separated PATH. os.pathsep is used correctly
on extra_paths in meson_exe.py, but not in mesontest.py
This is especially useful with the glib testing framework where you
can select which tests to run within a single test executable by
pasing `-p /some/test/path`
It would add --args to `wrap` repeatedly for each re-run, resulting in
gdb erroring out with `--args: No such file or directory.`
Also don't make --gdb and --wrapper mutually exclusive. Sometimes people
want to run under a wrapper *and* run it under gdb.
The setup's timeout multiplier will always be set, and it will default
to 1.0, so just use that.
Without this, the setup's timeout multiplier was always ignored.
When using a setup, use the setup name as the namebase for the logfile
instead of the wrapper. The wrapper may not be set, or it may be shared
between test setups.
Also don't try to use the wrapper if it's an empty list.
Closes https://github.com/mesonbuild/meson/issues/1371
The output is very confusing otherwise. Before it said
'No suitable tests defined' and then showed a list of tests that
passed/failed.
Now it will just say 'No suitable tests defined' and exit.
This is useful enough that we can enable this for everyone. If people
really don't want this, they can pass MALLOC_PERTURB_=0 in the
environment or in the test.
Back in November when this broke, we didn't notice because our tests
are run in-process, so we don't check that `msbuild RUN_TESTS.vcxproj`
and `ninja test` actually work.
Now we do.
For example if we know the tests takes more time because, for example
we are tracing it, or running with very high debug log level we might
not want the test to timeout.
In the normal case the user probably wants to set break point or
anything when running an app in gdb, we should let him a chance to
do so.
In the case he is running in a loop, it probably means he want to
reproduce a crash or a race inside gdb so we should just go and
run in gdb.
We probably miss a few options to give him more control.
Knowing whether a test failed to run as its prerequisites were not
available, or whether those prerequisites were available and produced
unexpected/incorrect results, is a useful differentiation.
Add support for skipped tests by testing for exit code 77, used through
autotools/piglit/etc to denote a test which detected this and decided to
skip.