Changes between Version 1 and Version 2 of Build Output Processing

Timestamp:

Aug 2, 2005, 1:20:17 PM (19 years ago)

Author:

cmlenz

Comment:

Added notes about parsing build messages

Build Output Processing

@@ -92 +92 @@
 Richer handling of output can be provided if the output of the tool is known and consistent. This applies for example to Ant output in XML format. Based on an XML-formatted build log, Bitten could break up the output into targets, tasks and messages. Messages are always qualified with a “priority” in the XML log, which is one of “debug”, “verbose”, “info”, “warning” or “error”. This allows more fine grained handling of build messages than just differentiating between messages written to the output or error streams.
 
- ''Note'': The {{{XmlLogger}}} option is employed by the CI system [http://cruisecontrol.sourceforge.net/ CruiseControl] to get the build output in a way that can later be transformed into a human-readable HTML rendering using XSLT.
+ ''Note'': The {{{XmlLogger}}} option is employed by the CI system [http://cruisecontrol.sourceforge.net/ CruiseControl] to get the build output in a way that can later be transformed into a human-readable HTML rendering using XSLT.
+
+But parsing the messages themselves can also be helpful, even for builds with output not structured as XML. Many tools use formatting conventions such as prepending messages with labels such as {{{warning:}}}, which can be used adjust the level/priority of the message. Also, many messages related to problems in files are formatted in a consistent way, commonly known to be compatible with Emacs and other tools, for example:
+
+{{{
+filename:line:column severity: message
+}}}
+
+Microsoft tools and some others use a different format, but many can be supported using regular expression matching against the log message.
+
+The filename and line number information extracted this way can be used to link directly from the build log to the corresponding part of the file in the Trac repository browser.