Alcatel-Lucent nmake Product Builder

Release Notes -- Alcatel-Lucent nmake 10

July 2008
[Table of Contents] [Previous Section] [Next Section]

2. New Features and Significant Enhancements

2.1 Experimental structured build logs

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 nmake@alcatel-lucent.com.

The initial implementation contains a new command xmakelog 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 makelog file created by the nmakelog command which appends to an existing makelog file.

Note that 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.

Environment variable 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:

• name - nmake target atom name.
• dir - current directory of action.
• stime - start date/time in format YYYY-MM-DDThh:mm:ss
• host - name of host executing the action.

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.

2.2 OS Version dependent probe files

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 export VERSION_OS in the environment.

The OS version is taken from uname() sysname and 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.

2.3 Support for recent Solaris C/C++ compilers

Sun Studio 12 has been certified with no issues. The Sun Studio -xcode=pic32 and -xcode=pic13 pic flags are now detected by probe (see 070034). Support for the Sun Studio -library and -compat 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 030057).

2.4 Improved support for Windows

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).

2.5 Fixes for Java builds

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 JARROOT changes (see 070014) and detecting when class files are removed from a jar and then put back (see 060059).

2.6 Experimental Eclipse plugin pre-release

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.

[Table of Contents] [Previous Section] [Next Section]