CMake 3.19 added a new COMMAND_ERROR_IS_FATAL option to the execute_process() command. The goal as originally stated in the issue was to be able to replace code like this:
execute_process(COMMAND foo RESULT_VARIABLE _result)
if(_result)
message(FATAL_ERROR "foo returned ${_result}, should be 0")
endif()
With something more concise, which ended up being this:
This change was made in MR 5243. In those discussions, we didn’t consider the effect of the TIMEOUT option. If the TIMEOUT option is used, we still have to provide a result variable and check it using the old method because it isn’t handled by COMMAND_ERROR_IS_FATAL. Should we consider this a bug in the implementation and fix it in 3.19.2, or is a timeout something we want to keep separate that COMMAND_ERROR_IS_FATAL should not catch?
COMMAND_ERROR_IS_FATAL is an error condition. It explicitly checks the return code and prints the error message. TIMEOUT sets the RESULT_VARIABLE.
If you want COMMAND_ERROR_IS_FATAL to catch timeout, how do you want this to be done?
If COMMAND_ERROR_IS_FATAL is not specified, TIMEOUT will set the RESULT_VARIABLE. Otherwise, it will fail with a message.
(I made a typo for the option name in my original post, which was repeated in your reply, I’ve corrected both to avoid future confusion)
No it doesn’t fail, it silently continues. That’s what makes this particularly dangerous because failures due to a timeout go unnoticed. It did that before 3.19 already, but with the new COMMAND_ERROR_IS_FATAL option, one could assume that new option also catches timeouts. It would be understandable to go with the reasoning that the command is still failing, it’s taking longer than expected and timing out. That’s exactly what I did, I only found out it didn’t catch it because I was explicitly checking the behavior before updating some documentation around the new option.