Alcatel-Lucent nmake Product Builder

Release Notes -- Alcatel-Lucent nmake 13

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

2. New Features and Significant Enhancements

2.1 Additional "explain" messages

"Explain" messages have been added to several cases where actions were triggered without a corresponding message. Explain messages are printed by nmake when the explain (-e) option is enabled to show why it is taking certain actions, in general explaining why actions are triggered. Explain messages are also captured in state files and structured build logs (see nmake 12 Release Notes).

The following messages have been added.

2.2 Improved support for Solaris 10 ksh

The Solaris 10 system ksh includes a change in behavior from previous Solaris releases that may impact use with nmake. It now initializes the PWD environment variable to the absolute, physical path of the current directory with no symbolic links. If /bin/ksh is started in a directory under a symbolic link then PWD is set to the path with no links which gives PWD a different value than the parent environment. The change appears to be intentional.

The new behavior can cause a problem with the nmake viewpath since the value of PWD must be under the first node in the VPATH. If your home directory is under a symbolic link then upon logging in PWD will be set to the physical path and may not match HOME, which can cause problems if HOME is used to set VPATH. Another issue is during a recursive build, nmake spawns new ksh and nmake processes to build sub-directories and makefiles. If a build is started under a symbolic link and the system ksh is spawned then PWD will not match the VPATH node.

nmake works around the new Solaris ksh behavior by detecting when PWD is a physical path under the logical node in the VPATH. When this is detected a warning is issued and nmake changes directory to the corresponding VPATH directory before processing the makefile. Spawned shell processes are also initialized with the expected value of PWD so recursive makes inherit the correct environment.

If the warning is encountered it is recommended to fix the environment by either changing the current directory to match the first node of the VPATH before starting the build, or changing VPATH to match PWD. Below is a simple example.

$ echo $PWD
/home/richb/builds/v1/src

$ echo $VPATH
/home/richb/node1

$ ls -ld /home/richb/node1
lrwxrwxrwx 1 richb richb 9 Jun 22  2010 /home/richb/node1 -> builds/v1

$ nmake
make: warning: PWD must be under the first VPATH node - PWD [/home/richb/builds/
v1/src] is physical path under VPATH [/home/richb/node1/src] logical path - chan
ging directory to logical path: /home/richb/node1/src
+ gcc -O -I- -c hello.c
+ gcc -O -o hello hello.o

$ cd /home/richb/node1/src

$ echo $PWD
/home/richb/node1/src

$ nmake clobber
+ ignore rm -f hello Makefile.mo Makefile.ms hello.o

$ nmake
+ gcc -O -I- -c hello.c
+ gcc -O -o hello hello.o

2.3 Certification for Oracle Solaris Studio 12 update 2

Oracle Solaris Studio 12.2 has been certified with nmake 13 with no issues. According to the Solaris Studio documentation as of Studio 12.1 the RogueWave headers and libraries (rw7) are deprecated and by default they are not searched by the C++ compiler. Therefore they do not get included in the default nmake search paths as well (CC.STDINCLUDE and CC.STDLIB probe variables). The RogueWave libraries can be accessed using the -library=rwtools7_std option to the C++ compiler. If the libraries are needed it is best to add this option to the nmake CC variable so the additional search directories will be picked up by nmake probe. For example:

CC = /opt/SUNWspro/bin/CC -library=rwtools7_std

2.4 Fixes in Java build support

Several improvements have been made to the Java build support.

• The :JAVA: operator is more consistent with the :: operator.
  • The install common action builds :JAVA: targets.
  • The all common action builds :JAVA: targets.
  • The :ALL: assertion action builds :JAVA: targets.
  • A default target is defined by :JAVA: to build the java code by default if it comes before another target in the makefile. This eliminates a source of the .dummy.java errors.
• A jar file inside a Java source package directory as defined with the :JAVA: operator no longer causes unnecessary rebuilds of the Java code.
• Removing a prerequisite of a :JAR: assertion from a makefile, rebuilding the jar target, and then adding the prerequisite back to the makefile correctly updates the jar target again.
• Changing the value of the JAVACLASSDEST variable in a :JAVA: makefile will update the Java dependencies and rebuild the Java code with the new class directory.

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