An experimental feature designed to generate structured build logs is being introduced. Build log structure is indicated through insertion of tags at appropriate locations in the build log, generally at the beginning and end of build output for each triggered action. The tags are user configurable with few restrictions on their format.
The initial release provides special support for XML format tags. This enables build log query, formatting, and transformation using standard XML tools. The implementation is still experimental and subject to change. We are interested in feedback and suggestions, please send comments to firstname.lastname@example.org.
The initial implementation contains a new command
that configures the feature to produce basic XML structured log files.
xmakelog accepts the same set of command line arguments as
that accepted by nmake. When
xmakelog is run structured
logs containing tags are generated into a secondary file called
makelog.xml (in the case of XML structured files) while
regular unstructured build commands appear on standard output as usual.
makelog.xml is created in the build directory from scratch
for each run. This is different from the
created by the
nmakelog command which appends to an existing
xmakelog is provided as as experimental interface to
the build log functionality. In future releases the functionality of
xmakelog may migrate into
nmakelog in which case
xmakelog may be deprecated.
makelog_format provides fine control
over the build log format. Examples:
makelog_format=xml:- Create basic XML formatted log. Each target element has a name attribute providing the target name.
makelog_format=xml:targ/@name,@dir- Create XML formatted with each target element having a name attribute and a dir attribute.
makelog_format=xml:targ/@- Create XML with each targ element populated with the complete set of supported attributes.
For example, specifying
makelog_format=xml:targ/@name,@dir,@host would result in tags
of the form
<targ name="abc" dir="dir" host="host">.
makelog_format syntax has elements of Xpath syntax.)
There is one targ element per triggered shell action. The current selectable set of available targ element attributes is:
The tags can be customized by setting a couple of action tag variables in your Makefile. This allows changing the generated XML elements and attributes, and even allows generating non-XML tags. For example, a basic XML formatted log is set up with the assignments:
action_tag_begin = echo '$(action_tag_marker)<targ name="$(<)">' action_tag_end = echo '$(action_tag_marker)</targ>"'
Here is a simple example using the defaults.
$ ls -l total 4 -rw-r--r-- 1 richb richb 26 Jul 2 16:46 Makefile -rw-r--r-- 1 richb richb 78 Jul 2 16:46 hello.c $ cat Makefile CC = gcc hello :: hello.c $ xmakelog + gcc -O -I- -c hello.c + gcc -O -o hello hello.o $ ls -l *.xml -rw-r--r-- 1 richb richb 153 Jul 2 16:46 makelog.xml $ cat makelog.xml <?xml version="1.0"?> <buildlog> <targ name="hello.o"> + gcc -O -I- -c hello.c </targ> <targ name="hello"> + gcc -O -o hello hello.o </targ> </buildlog>
For more details and examples see Generating Structured Build Logs.
Different probe files are now generated for different versions of the
operating system. This prevents a machine from using the wrong probe
configuration information that was generated on another OS version when
the same nmake installation is shared among multiple machines. The OS
version is stored in the new
CC.VERSION_OS probe variable
and is used as a probe attribute to determine the probe filename hash.
CC.VERSION_OS cannot be edited, to override the default
VERSION_OS in the environment.
The OS version is taken from uname()
release system information which can typically be seen
by running the command
uname -s -r. However on Linux
systems this generally only shows the kernel version; so on Linux only
the major.minor release numbers are used (e.g. "2.6") and distribution
specific release information is included. The Linux distribution
information is taken from release files in
/etc if found.
Sun Studio 12 has been certified with no issues.
The Sun Studio
pic flags are now detected by probe (see 070034).
Support for the Sun Studio
flags is improved (see 070016).
Compile problems caused by
-I flags seen with certain combinations
of the Solaris and compiler versions have been resolved (see
Windows based text editors and IDEs are now better supported. nmake can now read makefiles formatted as DOS style text files using two-byte newlines on all platforms. CTRL-M characters appearing at the end of a line are ignored. (see 060067).
Several enhancements for Java builds are included.
JDK 1.4.2 style class names are now properly supported in conjunction
with Javadeps alu2.2.4 (see 060005).
Updated jar support includes updating a target when
changes (see 070014) and
detecting when class files are removed from a jar and then put
back (see 060059).
An experimental Eclipse plugin is available as a separate download from our Eclipse update site. The plugin supports use of nmake with Eclipse, especially Eclipse CDT. This version supports Eclipse 3.3/CDT4.0/Linux, Solaris and the gcc/g++ tool chain.
The plugin currently provides managed build definitions that configure CDT for nmake builds for Makefile-based projects. The definitions leverage nmake "common actions" to pre-populate builder options with targets useful across a broad range of nmake-based projects. Out of the box, the plugin provides an nmake specific CDT Project Type and CDT build configurations for Debug and Release builds on several platforms. In common cases, the build definitions substantially reduce the need to manually specify build options for nmake based builds.
The plugin also provides C and C++ sample projects packaged as Eclipse CDT project templates. For the sample projects provided, the need for manual option setup is eliminated.
For more details and full documentation see the Eclipse support page.