| Alcatel-Lucent nmake Product Builder | |
Released: July 2008
1. Introduction
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
3.1 Baserules
3.2 cpp
3.3 Engine
3.4 Operators
3.5 Probe
3.6 Miscellaneous
3.7 Variables
3.8 Options
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
5.2 Remarks
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 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:
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
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.
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).
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 JARROOT
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.
LDFLAGS can 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 LDFLAGS
can 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.
CC variable instead of
CCLFAGS so 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 CC variable or suppressed by setting the nmake variable
libopts_warning to null in the makefile. Currently the
Sun -library and -compat flags are detected.
The new probe variable CC.LIBOPTS contains the affected
flags supported by the compiler. Here are examples of setting the
flag in the CC variable.
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 .c
file would include other .o files on the compile line
or $(>) would expand other unexpected files. To
expand prerequisites other than the primary metarule prerequisite
use the $(*) automatic variable.
$(>) 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 MAKELEVEL variable 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 MAKELEVEL should 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.2 is 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 JARROOT changes 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.MEMBERS probe variable. The new
CC.MEMBERS.UNDEF probe variable contains the linker option
to turn off force-load mode if one exists.
-I flag 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.OMIT probe variable. These directories
are still searched by nmake for dependencies but are not specified as
-I flags nor used by nmake cpp.
Different probe files are also now generated for different OS versions
using the new VERSION_OS probe 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_OS contains the
value of the current OS version and can be overridden by exporting
VERSION_OS in the environment.
For details see - New Features and Enhancements:
OS Version dependent probe files.
-xcode=pic32 and -xcode=pic13 before
-KPIC and -Kpic for setting the
CC.PIC probe variable. Manual pages for the recent Sun
Studio compilers indicate -KPIC and -Kpic
are obsolete.
See also - Changes Impacting alu3.9 Makefiles:
Using -KPIC/-Kpic with Sun Studio compilers.
CC.DYNAMIC probe variable
now mention the variable may be null when the tool chain generates shared
libraries by default. Checks for dynamic functionality should use
CC.DIALECT.
javadeps=1 has been clarified in the
:JAVA: manual page --
javadeps=1 triggers 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=1 whenever
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.
nmakelog script where it was possible
for the script to exit while logfilter was 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.
-KPIC and -Kpic flags are obsolete and
the -xcode=pic32 and -xcode=pic13 flags
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=pic32 for the pic flag when using these
compilers.
If -KPIC or -Kpic are hard-coded in
CCFLAGS for 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 :: operator.
-xcode=pic32 and -xcode=pic13 pic flags
such as Sun Studio.
CC.PIC instead of hard-coding
the pic flag. This also provides portability since
CC.PIC will be set correctly for different compilers
and platforms. For example:
CCFLAGS = $(CC.PIC)When adding to
CCFLAGS use the following to delay variable
expansion:
CCFLAGS += $$(CC.PIC)
\r\n
sequences 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\n sequences in their makefiles.
0D as
\x0D in nmake.
$ 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'
MAKELEVEL variableMAKELEVEL variable is now incremented in the parent
make when setting up the environment for all shell action blocks.
In alu3.9 MAKELEVEL was incremented at .MAKEINIT
time in sub-makes. The new approach makes the new value of
MAKELEVEL uniformly available throughout sub-make and
action block execution. However, it leads to an incompatibility when
accessing MAKELEVEL directly from shell action blocks.
For example, in the shell action of a first level sub-make,
$MAKELEVEL used to expand to 0, now it expands to 1.
MAKELEVEL variable in shell action blocks.
MAKELEVEL as an nmake variable
(e.g. $(MAKELEVEL)) and not a shell variable (e.g.
$MAKELEVEL).
The following is a list of known problems:
link
variable) 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.REPOSITORY is defined and
CC.DIALECT contains either PTRIMPLICIT or
PTRMKDIR, and ::
is used to trigger the metarule. Note that CC.REPOSITORY
and CC.DIALECT are defined as such in the probe file
for some C++ compilers.
The work-around is to add .IMPLICIT to the ::
assertion, or to not use the :: assertion (such as add
the target to :ALL: instead.)
force_shared=1.
%.c, the first metarule defined matching an existing
file will be triggered instead of the metarule matching the explicit file
prerequisite.
SHELL environment 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 SHELL to another version
of ksh that does not generate the warning, such as ksh88.