Nokia

Nokia nmake Product Builder

 

Nokia nmake Product Builder
nmake 10 Release Notes

Table of Contents

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


1. Introduction

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.

1.1 Release Number

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

1.2 Supported Hardware

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.

1.3 Hardware Requirements

1.4 Software Requirements

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

1.5 Customer Support

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.


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:

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.

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.


3. Bug Fixes and Enhancements

3.1 Baserules

  1. 040033 - link archive libs in shared lib target
    Shared library targets made with the double colon operator (::) can now be linked with archive library prerequisites.
  2. 060009 - LDFLAGS for shared libraries
    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
    
  3. 060019 - .SHARED.o strips ../ files from link line
    Shared libraries can now be generated with object files that begin with a path of "../". Previously, paths starting with "." were stripped from the link line.
  4. 070016 - Sun -library=x flag should be in CC variable
    Compiler flags that alter the tool's default header and/or library search paths should be included in the 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
    
  5. 080011 - experimental support for configurable structured build logs
    Experimental support for configurable structured build logs has been introduced. For example, XML based build logs can be generated.
    For details see - New Features and Enhancements: Experimental structured build logs.

3.2 cpp

  1. No changes to cpp in this release.

3.3 Engine

  1. 040043 - metarule $(>) expands non-matching prerequisites
    The behavior of the $(>) 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.
  2. 050032 - lost .ATTRIBUTEs
    A problem has been fixed where two internal attributes clashed with user defined attributes causing the user attributes to be set and unset unexpectedly. The clash has been eliminated and the user attributes are no longer affected.
  3. 050051 - $(>) expands too many files
    The $(>) automatic variable no longer expands unexpected files in metarules. See change 040043 for more information.
  4. 060067 - CTRL-M in files
    Makefiles containing DOS style two-byte newlines can now be properly read and parsed on all platforms. nmake ignores CTRL-M characters at the end of a line allowing better integration with Windows based text editors and IDEs.
    See also - Changes Impacting alu3.9 Makefiles: CTRL-M at the end of a line.
  5. 080004 - recurse messages output too late
    There are now three distinct recurse message types: default, gnu and custom. The types are not compatible; changing type during a recursive make is not supported and will result in a warning. GNU style recurse messages (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.

3.4 Operators

  1. 060005 - jdk 1.4.2 uses jdk 1.5 style class names
    JDK 1.4.2 is now supported by the :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.
  2. 060020 - files with : in name break :MAKE: *
    The :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.
  3. 060059 - jar not updated when file is removed and put back
    If a class file was removed in an incremental build and then put back in another incremental build such that its time stamp didn't change then the :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.
  4. 070014 - JARROOT change does not trigger update
    The :JAR: operator will now regenerate a jar target with the new root when JARROOT changes but the list of prerequisite classes do not.
  5. 080003 - excessively long library creation commands
    The :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.

3.5 Probe

  1. 030057 - obtain and test Sun C++ 7.x series compiler
    System or compiler include directories that result in a compile error when specified with a -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.
  2. 070034 - Studio 10 obsoletes -KPIC
    To support the new Sun Studio compiler flags, probe now detects pic flags -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.
  3. 070041 - g++ CC.DYNAMIC probe
    The probe file comments for the 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.

3.6 Miscellaneous

  1. 070030 - certify Sun Studio 12
    Sun Studio 12 was tested and no issues were found.
  2. 070036 - update man pages for Alcatel-Lucent
    The Java related man pages have been updated for Alcatel-Lucent.
  3. 060065 - javadeps=1 description confusing in man page
    The description of 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.
  4. 070039 - clarify rhs files in :JAR: man page
    The following clarification was added to the notes section of the :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.
  5. 080005 - missing makelog output file
    Fixed a problem in the 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.

3.7 Variables

  1. New variable CC.VERSION_OS - see 030057.
  2. New variable CC.STDINCLUDE.OMIT - see 030057.
  3. New variable CC.LIBOPTS - see 070016.
  4. New variable libopts_warning - see 070016.
  5. New variable CC.MEMBERS.UNDEF - see 080003.
  6. Change to variable MAKELEVEL - see 080004.

3.8 Options

  1. No changes to the options in this release.

4. Changes Impacting alu3.9 Makefiles

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.

4.1 Using -KPIC/-Kpic with Sun Studio compilers

Description
The man pages for the recent Sun Studio compilers indicate the -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.
Who is affected
Projects using compilers that support -xcode=pic32 and -xcode=pic13 pic flags such as Sun Studio.
What to do
Use the probe variable 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)

4.2 CTRL-M at the end of a line

Description
When reading a makefile CTRL-M characters at the end of a line are now ignored to support DOS style text files. Literal \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'
Who is affected
Projects using literal \r\n sequences in their makefiles.
What to do
Use escape sequences. Using the above example, CTRL-M can be represented using its hexadecimal value 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'

4.3 The MAKELEVEL variable

Description
The MAKELEVEL 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.
Who is affected
Projects using the MAKELEVEL variable in shell action blocks.
What to do
For uniform behavior reference MAKELEVEL as an nmake variable (e.g. $(MAKELEVEL)) and not a shell variable (e.g. $MAKELEVEL).


5. Known Problems and Remarks

5.1 Known Problems

The following is a list of known problems:

  1. 980009 - problem in link=*
    The problem about using linking (specified using the 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.
  2. 030042 - :cc: generated header rebuild
    If a C file is built by using :cc: and this C file shares a generated header file with a C++ file specified in the same makefile, the generated header file may get regenerated during the build causing the source files to keep recompiling. This can be avoided by building the C++ files before the C files, or by generating the header file in a separate makefile at an earlier time during the build.
  3. 990099 - metarules not searched when CC.REPOSITORY is set
    The metarules may not be searched under the following conditions: there is a user defined metarule for a non-compiled file, variable 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.)
  4. 020018 - adding shared lib building in same makefile won't re-link
    An executable target will not be re-linked when a shared library that is built in the same makefile is added as a prerequisite to the executable. The work-around is to set force_shared=1.
  5. 020051 - first metarule is used by mistake
    When multiple metarules generate the same source file target, such as %.c, the first metarule defined matching an existing file will be triggered instead of the metarule matching the explicit file prerequisite.
  6. 070010 - fails to bind large files
    nmake does not have large file support and cannot reference files over 2 GiB in size.

5.2 Remarks

  1. :LINK: does not handle archive files that are generated by :: or :LIBRARY: assertion operators. Users should avoid use of :LINK: on archive files.
  2. When the cpp -I-S flag is on, -D-M is disabled. Users should not use these two flags together.
  3. Users should avoid including the same header file with both <...>-style and "..."-style #include statements in source files managed by a single makefile. nmake will assign .STD.INCLUDE and .LCL.INCLUDE attributes to the header file, and this can result in incorrect -I lists in the compiler command lines generated.
  4. When the 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.

Last Update: Friday,12-Aug-2016 12:24:05 EDT