Fatal errors not halting processing

[craig.scott]

In writing the responses below, I feel like I’ve brought at least some of these points up before, but I could only find issues which relate to the message() command, which is different but has some overlapping discussions:

• 22131 - Make CMake errors (sent via SEND_ERROR) reporting more beginner friendly
• 19351 - CMake Error: FATAL_ERROR v. SEND_ERROR
• 22172 - Add new ERROR and ERROR_DEFERRED keywords to message()

@marc.chevrier

From another point of view, halting processing at the first error is a bit painful when you are writing CMakeLists.txt files: It requires a lot of cycles of edition/run to fix all errors!

For example, a c/c++ compiler does not work like this: When you compile a file with multiple errors, the compiler try to achieve the compilation of the file (if possible) and show multiple errors… So you can fix all the errors at once before launching a new compilation!

CMake is different to a compiler, it caches things between runs. If you don’t stop on the first error, the code that follows it might make a wrong decision and cache that wrong result. Then, even after you fix the error, the cached wrong result is kept. This is something I would expect most users to overlook, especially in big, complex projects.

@marc.chevrier

Maybe the right solution is to introduce a cmake option (like --stop-on-error) to control the behavior of processing: stop or continue on fatal error…

CMake is already inconsistent in when it stops immediately and when it doesn’t. For example, a find_package(Blah REQUIRED) will halt immediately if it doesn’t find the requested package. I ended up starting this discussion because I kept seeing CMake continue processing way past errors in large, complex projects. In some cases, there is a lot of configure output and just finding the error is a pain. I am finding CMake’s current lack of consistency and the commands that allow processing to continue to be a much more common problem than wishing I could have processing continue past a given error. I think it should be consistent and always halt. If you really want to allow execution to go past that, I’d say maybe add an option for that rather than requiring an option to make it halt on first error.

We don’t even have to worry about a policy here, since we are talking about fatal errors. Any affected behavior is already resulting in a non-functional project, so we don’t have to preserve the current behavior.