Expose the test timeout as an env var?

[krader1961]

In the Korn Shell project we need to know the test timeout that Meson applies to a specific test. This is because we want to forcibly terminate an expect based unit test one second prior to the timeout in order to capture more information in the Meson test log. Specifically, the expect output produced by its log function. This does result in Meson reporting a test failure rather than a timeout which is somewhat unfortunate. But it also means the Meson test log contains much more useful information about the state of the expect based test that would have otherwise been reported as timed out by Meson.

I would be happy if the value was exposed in the environment via MESON_TEST_TIMEOUT or something similar.

[scivision]

Setting environment variable difficulties were previously discussed in https://github.com/mesonbuild/meson/issues/541

When I've just had to set/get environment variables, I've done it with run_command() and a one or two line Python script. I think that could work here perhaps.

[krader1961]

@scivision, The problem isn't setting the env var. That's already possible and we do take advantage of the capability. For example:

        lang_var = 'LANG=en_US.UTF-8'
        test(test_name, ksh93_exe, timeout: timeout, is_parallel: parallel,
            args: [test_driver, test_name],
            env: [shell_var, lang_var, src_root, test_root, ld_library_path, libsample_path])

We would use the mechanism to set the env var ourselves but the problem is that there doesn't seem to be any way to get the test timeout multiplier. It would be sufficient if that value was accessible via get_option('timeout_multipler') or via the meson object. Meson doesn't have to automatically export the timeout as I suggested in my first comment.

[jpakkane]

Note that if/when #6515 gets merged, we will first send a SIGTERM so you could add a handler for that and dump the info from there.

[krader1961]

@jpakkane Yes, the SIGTERM mechanism in #6515 would also be a viable, and perhaps more robust and generally applicable, mechanism for my use case. However, as noted in the discussion of that P.R. dealing correctly with child processes of the top-level test processes which trap SIGTERM can be problematic. One solution to that is to simply punt the problem to the unit test writer. Tell them that if any processes spawned by the top-level test process catch SIGTERM then the top-level test process must also do so and ensure any processes it spawned are killed when it receives SIGTERM.

[camilo-celis]

@krader1961 just a heads-up that #6515 has been merged.