Released: July 2008
1.1 Release Number
1.2 Supported Hardware
1.3 Hardware Requirements
1.4 Software Requirements
1.5 Customer Support
2. New Features and Significant Enhancements
2.1 Experimental structured build logs
2.2 OS Version dependent probe files
2.3 Support for recent Solaris C/C++ compilers
2.4 Improved support for Windows
2.5 Fixes for Java builds
2.6 Experimental Eclipse plugin pre-release
3. Bug Fixes and Enhancements
4. Changes Impacting alu3.9 Makefiles
4.1 Using -KPIC/-Kpic with Sun Studio compilers
4.2 CTRL-M at the end of a line
4.3 The MAKELEVEL variable
5. Known Problems and Remarks
5.1 Known Problems
This document announces the new release of nmake version 10. nmake is fully supported and is in wide production use throughout Alcatel-Lucent, AT&T, and elsewhere.
These nmake 10 Release Notes discuss in detail the new features, and highlight bug fixes, additional enhancements, and known problems.
The release numbering scheme has changed. Starting with this release the major release number is being dropped and releases are numbered incrementally starting from "10". The previous release was "alu3.9".
The nmake 10 release has been ported to many UNIX-based and UNIX-like systems. For a current list see the Availability Chart on the nmake web site, http://www.bell-labs.com/project/nmake/. Or contact the Customer Support helpdesk below.
The nmake 10 release is available for HP-UX, Linux, Solaris, and Windows (under SFU/Interix). See the nmake 10 download page for a listing of available distribution packages. nmake is generally upward compatible with later OS releases in a series (for example, the series Solaris 2.5 through 2.10); contact Technical Support with any compatibility questions or with any requests for porting to other systems.
The Windows-based version of nmake is based on the Windows Services for UNIX (SFU/Interix) porting/development environment from Microsoft and requires installation of the SFU package in order to run. The SFU package must be obtained from Microsoft and installed following their installation procedure. For more information see the Support for Windows page.
nmake 10 provides dependency-based Java build support. This feature currently requires an external Java source scanner called JavaDeps to extract inter-modules dependencies from Java source. nmake 10 requires JavaDeps release lu2.2.4; this version is downloadable from the nmake JavaDeps page. Installation instructions are also on that page. THIS PACKAGE IS ONLY REQUIRED BY PROJECTS PERFORMING JAVA BUILDS USING THE :JAVA: ASSERTION OPERATOR. JavaDeps release lu2.2.4 is itself written in Java; it requires jdk1.2.1 or higher version on its PATH in order to run. (Note that this does not restrict the project being built to jdk1.2.1 or higher.)
We provide patch support, where code changes are required, for the latest 2 point releases of nmake (currently releases nmake 10 and alu3.9). Customers using older releases can still acquire help in using the product, but genuine problems found in older releases will not be fixed. Such problems may require an upgrade to a current release or, when possible, a makefile work-around will be provided.
Fee-based services are also available. These include makefile rewrites, conversion of non-nmake makefiles to nmake, integration with vendor tools, build assessments, and porting nmake to new machines.
Contact Customer Support for any questions regarding nmake.
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.
::) can now be linked with archive library prerequisites.
LDFLAGScan now be used to specify link flags when creating shared libraries with a Sun C++ compiler. It previously only worked with other compilers. If necessary
LDFLAGScan be defined on a per-target basis as follows:
libabc.so :: abc.c LDFLAGS=-flag xyz :LIBRARY: xyz.c libxyz.so.1.0 : LDFLAGS=-flag
../". Previously, paths starting with "." were stripped from the link line.
CCvariable instead of
CCLFAGSso the compiler is probed in the proper mode and the nmake probe configuration includes the modified search paths. A warning is now issued when such a flag is included in
CCFLAGS. The warning can be eliminated by moving the flag to the
CCvariable or suppressed by setting the nmake variable
libopts_warningto null in the makefile. Currently the Sun
-compatflags are detected. The new probe variable
CC.LIBOPTScontains the affected flags supported by the compiler. Here are examples of setting the flag in the
CC = /opt/SUNWspro/bin/CC -library=iostream
CC += -library=iostream
$(>)automatic variable in metarules has been restored to the original behavior prior to release lu3.6 and has been properly documented (see lu3.6 Release Notes, change 010035). The restored behavior provides more consistent and predictable behavior. In metarules, the
$(>)automatic variable expands only the primary metarule prerequisite, which is the first %-pattern prerequisite of the rule, and is never null. This eliminates problems where, under certain conditions, a compile of a
.cfile would include other
.ofiles on the compile line or
$(>)would expand other unexpected files. To expand prerequisites other than the primary metarule prerequisite use the
$(>)automatic variable no longer expands unexpected files in metarules. See change 040043 for more information.
recurse_begin_message=gnu) are now output in sub-makes at the very beginning (before engine bootstrap) and very end of an nmake run. This is useful when using nmake with development tools that use the GNU recurse messages to track the current directory in recursive builds. Tools such as Eclipse can now perform accurate tracking of all errors encountered during a run including early errors output by nmake itself. The
MAKELEVELvariable is now incremented in the parent make when setting up the environment, making the new value uniformly available throughout sub-make and action block execution. References to
MAKELEVELshould only use the nmake variable
$(MAKELEVEL). See also - Changes Impacting alu3.9 Makefiles: The MAKELEVEL Variable.
:JAVA:operator. When using JDK 1.4.2 to compile Java code the flag
--javaversion=1.4.2is passed to Javadeps to generate JDK 1.4.2 style class names for the targets and dependencies. The JDK 1.4.2 style names are slightly different than both the JDK 1.4.1 and JDK 1.5. Javadeps version alu2.2.4 is required.
:MAKE:operator can now recurse to directories containing a colon (
:) in their name. Previously this caused an error. Makefiles containing a colon in the name are not supported.
:JAR:operator would not add the class file back to the jar after deleting it in the first incremental build. The
:JAR:operator now properly handles this scenario and will add the class file back to the target jar file as expected.
:JAR:operator will now regenerate a jar target with the new root when
JARROOTchanges but the list of prerequisite classes do not.
:LIBRARY:operator has been enhanced to use linker options where available to tell the linker to pull in all members from an archive when creating a shared library from the archive. This eliminates the huge linker command lines since each symbol is not listed on the command line. The force-load linker option is stored in the
CC.MEMBERSprobe variable. The new
CC.MEMBERS.UNDEFprobe variable contains the linker option to turn off force-load mode if one exists.
-Iflag on the compile line are no longer included on the compile line. Probe attempts to identify such include directories and lists them in the new
CC.STDINCLUDE.OMITprobe variable. These directories are still searched by nmake for dependencies but are not specified as
-Iflags nor used by nmake cpp. Different probe files are also now generated for different OS versions using the new
VERSION_OSprobe attribute. This prevents nmake from using probe configuration data for another operating system version which can be different. This is useful when the nmake installation is shared among machines running different versions of the OS. The probe variable
CC.VERSION_OScontains the value of the current OS version and can be overridden by exporting
VERSION_OSin the environment. For details see - New Features and Enhancements: OS Version dependent probe files.
-Kpicfor setting the
CC.PICprobe variable. Manual pages for the recent Sun Studio compilers indicate
-Kpicare obsolete. See also - Changes Impacting alu3.9 Makefiles: Using -KPIC/-Kpic with Sun Studio compilers.
CC.DYNAMICprobe variable now mention the variable may be null when the tool chain generates shared libraries by default. Checks for dynamic functionality should use
javadeps=1has been clarified in the
:JAVA:manual page --
javadeps=1triggers an incremental update of the Java file dependencies (out-of-date source files are rescanned for dependency information). For performance reasons the user is responsible for setting
javadeps=1whenever Java source is changed in a way that modifies the dependencies.
:JAR:man page: If a rhs file contains no ksh pattern characters then pattern matching is not used to generate a list of prerequisites and the prerequisite is taken as specified. If such a file does not exist in the viewpath nmake will issue an error for the missing file. If the rhs file contains a ksh pattern then pattern matching is used to generate the prerequisite list and no errors are generated for missing files. A warning is generated if no files are found to match the rhs patterns.
nmakelogscript where it was possible for the script to exit while
logfilterwas still running in the background resulting in the fifo being deleted early. The script now waits for the background process to finish before exiting.
CC.VERSION_OS- see 030057.
CC.STDINCLUDE.OMIT- see 030057.
CC.LIBOPTS- see 070016.
libopts_warning- see 070016.
CC.MEMBERS.UNDEF- see 080003.
MAKELEVEL- see 080004.
The changes in nmake 10 are largely backward compatible with alu3.9. Every effort has been made to insure code changes do not unexpectedly change the documented behavior of nmake features.
The following may impact builds and require changes.
-Kpicflags are obsolete and the
-xcode=pic13flags should be used instead. The probe tool now detects the new flags before the old ones and will typically set probe variable
CC.PIC=-xcode=pic32for the pic flag when using these compilers. If
-Kpicare hard-coded in
CCFLAGSfor building a shared library nmake will not be able to detect the pic flag and may not generate a shared library with the
:LIBRARY:operator or may issue a warning with the
-xcode=pic13pic flags such as Sun Studio.
CC.PICinstead of hard-coding the pic flag. This also provides portability since
CC.PICwill be set correctly for different compilers and platforms. For example:
CCFLAGS = $(CC.PIC)When adding to
CCFLAGSuse the following to delay variable expansion:
CCFLAGS += $$(CC.PIC)
\r\nsequences in makefiles or job action blocks are changed to literal
\n, possibly changing program behavior. These cases are believed to be rare. It is recommended to change such cases to use equivalent escape sequences. Here is a simple example:
$ cat Makefile a= 'y^M z' t : .MAKE print $(a:C|\r|e|:C|\n|f|) $ od -cb Makefile 0000000 a = ' y \r \n z ' \n \n t : . 141 075 040 047 171 015 012 172 047 012 012 164 040 072 040 056 0000020 M A K E \n \t p r i n t $ ( a : 115 101 113 105 012 011 160 162 151 156 164 040 044 050 141 072 0000040 C | \ r | e | : C | \ n | f | ) 103 174 134 162 174 145 174 072 103 174 134 156 174 146 174 051 0000060 \n 040 012 0000062 # Old nmake: $ nmake 'yefz' # New nmake: $ nmake 'yfz'
\r\nsequences in their makefiles.
$ cat Makefile a= 'y$("\x0D") z' t : .MAKE print $(a:C|\r|e|:C|\n|f|) $ nmake 'yefz' $ cat Makefile a= 'y$("\x0D")$("\x0A")z' t : .MAKE print $(a:C|\r|e|:C|\n|f|) $ nmake 'yefz'
MAKELEVELvariable is now incremented in the parent make when setting up the environment for all shell action blocks. In alu3.9
MAKELEVELwas incremented at
.MAKEINITtime in sub-makes. The new approach makes the new value of
MAKELEVELuniformly available throughout sub-make and action block execution. However, it leads to an incompatibility when accessing
MAKELEVELdirectly from shell action blocks. For example, in the shell action of a first level sub-make,
$MAKELEVELused to expand to 0, now it expands to 1.
MAKELEVELvariable in shell action blocks.
MAKELEVELas an nmake variable (e.g.
$(MAKELEVEL)) and not a shell variable (e.g.
The following is a list of known problems:
linkvariable) to install targets in any adjacent nodes in viewpathing still exists. You may still use linking to install, but only in alternate nodes -- installation using copying must alternate with installation using linking. The problem occurs with both symbolic and hard linking.
CC.REPOSITORYis defined and
::is used to trigger the metarule. Note that
CC.DIALECTare defined as such in the probe file for some C++ compilers. The work-around is to add
::assertion, or to not use the
::assertion (such as add the target to
%.c, the first metarule defined matching an existing file will be triggered instead of the metarule matching the explicit file prerequisite.
SHELLenvironment variable points to ksh93 you may get the following warnings when building your shell scripts:
warning: line 1: `...` obsolete, use $(...). The warning is generated running your script with
ksh -n. To eliminate the warning either update your shell scripts as indicated by the message or set
SHELLto another version of ksh that does not generate the warning, such as ksh88.