Indenting of messages
Changes in !3464 (merged) propose adding support for project-controlled indenting of messages. This has highlighted that the current state of message indenting is a bit of a mix depending on the message type, so it isn't immediately obvious how to implement further indenting control in a way that is consistent and intuitive for project authors. This issue was created to discuss the way forward.
The current state of message indenting as of CMake 3.14.5 can be summarised as follows:
-
Messages of NOTICE level are output exactly as provided.
-
Warning and error messages are preceded by a line indicating the source of the message and that line is never indented. The handling of the actual warning or error message may apply a degree of markup. If a message is indented (i.e. starts with a space), it is treated as pre-formatted. For unindented messages, they will be automatically line-wrapped to 77 character line width. An automatic indent of two spaces is applied to each line of the message, regardless of whether it is treated as pre-formatted or not. It also seems that two extra newlines are appended after the warning or error message.
-
STATUS messages and lower have
--
prepended to the start of the message. If a multi-line message is given,--
is only prepended to the first line. No automatic line wrapping is performed and messages are never treated as pre-formatted.
There are multiple code paths through which messages can be constructed and finally logged. Some go through cmSystemTools::Message()
, some through cmMakefile::DisplayStatus()
and others through cmMessenger::DisplayMessage()
. All three do different things with regard to how the message is modified and sent to its final destination, so any change to indenting behaviour will need to consider each of the different methods.
Some questions that need to be answered for any new indenting support include:
-
Should indenting apply to warning and error messages?
-
Should indenting be applied to all lines of a multi-line message or only the first?
-
Should arbitrary/custom padding be allowed or should indenting be restricted to a set number of spaces? Hierarchal projects may mix projects with different ideas about indenting and the hierarchy can be arbitrarily deep (so potentially leading to many levels of indenting). Allowing custom padding may result in mixed indenting that could become confusing/misleading. On the other hand, custom padding may allow more flexibility in the way indenting could be used (no specific scenarios come to mind at the moment though).