[cmake-developers] Fatal errors sometimes lead to infinite while loops. 2.8.12.1 bug?

[Alan W. Irwin]

If you design a simple test case such as

project(test_loop_fatal_errors NONE)
cmake_minimum_required(VERSION 2.8.12.1 FATAL_ERROR)

while(1)
   message(FATAL_ERROR "Should stop loop?")
   message(STATUS "Did I make it by FATAL_ERROR?")
endwhile(1)

The result is the expected one; the loop stops immediately.

irwin at raven> cmake ..
CMake Error at CMakeLists.txt:5 (message):
   Should stop loop?


-- Configuring incomplete, errors occurred!
See also "/home/irwin/test_cmake1/build_dir/CMakeFiles/CMakeOutput.log".

But if you replace

message(FATAL_ERROR "Should stop loop?") ==>
add_subdirectory(non_existent_directory)

in the above CMake logic you get an infinite loop despite the FATAL error from the
add_subdirectory command.

irwin at raven> cmake ..
CMake Error at CMakeLists.txt:5 (add_subdirectory):
   add_subdirectory given source "non_existent_directory" which is not an
   existing directory.


-- Did I make it by FATAL_ERROR?
CMake Error at CMakeLists.txt:5 (add_subdirectory):
   add_subdirectory given source "non_existent_directory" which is not an
   existing directory.


-- Did I make it by FATAL_ERROR?

These messages repeat indefinitely unless you ctrl-C out of it.

I arrived at the simple experiments above because I also had a much
more complicated example which used an outer while loop, and
add_subdirectory to various legitimate directories inside the loop.
However, one of those subdirectories had a simple FATAL_ERROR message
that my own cmake code generated when the logic failed to find something
that was needed.  But much to my surprise instead of getting an
immediate stop, the result was an infinite loop!  And using break()
rather than message(FATAL_ERROR ....) was impractical for this case
because it was buried deeply inside several loops and a function.

So obviously there are some conditions where message(FATAL_ERROR ...)
does not immediately stop processing contrary to the documentation
which says:

FATAL_ERROR    = CMake Error, stop processing and generation

I personally think this is a bug (in CMake-2.8.12.1 and presumably
prior versions to that) that should be fixed because some method of
unequivocally stopping all processing under all conditions is
extremely useful to have, and it appears that message(FATAL_ERROR ...)
is the only possible way to accomplish that under cmake.

Of course, this issue with FATAL_ERROR conditions sometimes not
stopping processing emphasizes the non-robust nature of while loops
where some component of CMake logic not working quite as expected
turns them into infinite loops as in the second simple example above.
Until "message(FATAL_ERROR)" is fixed, I have worked around this issue
by replacing the outer while loop with the foreach loop near equivalent
(using a sensible RANGE and using break() to get out of the outer loop when
the condition is no longer satisfied).

Nevertheless, despite the availability of the above workaround to
replace while loops by the almost equivalent foreach RANGE loop, it is
pretty important in my opinion that message(FATAL_ERROR ....)
guarantees a stop in processing as its documentation states. I will
write this up as a bug error report if the CMake developers here agree
this is a bug.  Of course, ideally I won't have to initiate that bug
triage process if a CMake developer here does a quick check and finds,
for example, that the C++ code that implements add_subdirectory needs
an obvious fix to properly support CMake error conditions and thus
turn the second simple example above from an infinite loop into the
expected immediate stop.

Alan
__________________________
Alan W. Irwin

Astronomical research affiliation with Department of Physics and Astronomy,
University of Victoria (astrowww.phys.uvic.ca).

Programming affiliations with the FreeEOS equation-of-state
implementation for stellar interiors (freeeos.sf.net); the Time
Ephemerides project (timeephem.sf.net); PLplot scientific plotting
software package (plplot.sf.net); the libLASi project
(unifont.org/lasi); the Loads of Linux Links project (loll.sf.net);
and the Linux Brochure Project (lbproject.sf.net).
__________________________

Linux-powered Science
__________________________