"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.
|no file for target target||target is made because the generated target file does not exist|
|target has .FORCE attribute||target is triggered because its action is forced with the .FORCE special atom|
|target force option enabled||target is updated because the force (-F) option is enabled|
|target :cc: sub-make update (see null.ms)||target is made by a sub-make process to compile :cc: files, for details run nmake -lef null.ms|
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
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
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
not match the
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
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
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
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.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
Several improvements have been made to the Java build support.
:JAVA:operator is more consistent with the
:ALL:assertion action builds
:JAVA:to build the java code by default if it comes before another target in the makefile. This eliminates a source of the
:JAVA:operator no longer causes unnecessary rebuilds of the Java code.
:JAR:assertion from a makefile, rebuilding the jar target, and then adding the prerequisite back to the makefile correctly updates the jar target again.
JAVACLASSDESTvariable in a
:JAVA:makefile will update the Java dependencies and rebuild the Java code with the new class directory.