A mistake in the implementation of the :I edit operator that occasionally resulted in incorrect output, has been fixed. You can easily check your version - just hand the following makefile
VAR1 = a b VAR2 = b c t : .MAKE print Intersection: $(VAR1:I=$(VAR2)) x : b c
to nmake and if you don't get
you need to upgrade.
The :P=D edit operator could, under unusual circumstances, incorrectly decide that a pathname listed in a .SOURCE rule represented a simple file rather than a directory. Once that mistake was made :P=D removed the trailing component from the pathname and returned the resulting directory as the answer. The problem exists in all recent versions of nmake and has now been fixed.
A mistake in code added to the :G edit operator in 3.1 that occasionally resulted in an incomplete list of generated files, has been fixed. The bug is illustrated by the following example,
SRC = tst.idm %b.c : %.idm .TERMINAL touch $(<) t : .MAKE print Generated files: $(SRC:G=%.o)
Generated files: tstb.o
if your version of nmake is working properly.
Listings of large directories using the :L edit operator could cause a core dump. The problem happened when an internal buffer was automatically expanded and moved by realloc(), but a local pointer into that buffer was not updated. The mistake is an old one that's now fixed.
The following makefile
t : .MAKE .FORCE .ALWAYS print $(...:P=U)
illustrates a problem with the :P=U edit operator that usually ends with a core dump. This is another very old bug that's fixed in 3.1.1.
Several file scanning problems were found and fixed in this release.
#include <msg.h>between builds. A bug introduced in 3.1 sometimes prevented the re-scan of the source file, so msg.h could inherit .LCL.INCLUDE from the statefile, but without scanning .STD.INCLUDE would never be assigned to msg.h . The mistake has been corrected in 3.1.1.
file1.c: #include "header1.h" file2.c: #include "header2.h" header1.h: #ifndef _HEADER1_H #define _HEADER1_H 1 #include "header1.h" #endif header2.h: #ifndef _HEADER2_H #define _HEADER2_H 1 #include "header1.h" #endif Makefile: .MAIN : file1.o file2.o file1.o : unbind unbind : .AFTER .MAKE .FORCE .VIRTUAL .UNBIND : header1.h header2.hThe problem was introduced in 3.0.2 and fixed in 3.1.1.
nmake occasionally lost track of information that it might need later on to calculate a file's bound directory. A typical example is a source file with an include directive
and a .SOURCE.h rule
.SOURCE.h : ../../hdr
used to locate header files. After binding the include file to
nmake correctly simplified the bound path to
in a process called path canonicalization, and then associated the simplified path with the unbound name. In our example the bound directory is,
but there's no longer a record of it in the canonicalized path. nmake usually anticipated problems and took steps to record the bound directory elsewhere, but a few cases slipped by. The omissions have now been fixed.
A long-standing mistake in nmake metarule code made assertions like
../%.t : $(DIR)/%.p action
difficult to use, because nmake usually started from the target's directory when it went looking for the prerequisite. The mistake, which was caused by a missing test in an if statement, has now been fixed. (Users who recognized the behavior and managed to work around it may have some incompatibilities to deal with when they upgrade to 3.1.1. There's a magic incantation that restores the old behavior, but it's a last resort that we're not giving out here.)
#endif /* this is itat the end of an input file no longer sends cpp into an infinite loop.
#pragma optionhave been fixed.
#define Y##Bweren't handled properly. The mistake has been fixed in this release.
--prelink_copy_if_nonlocalhelps C++ 4.1's template instantiation work with nmake viewpathing.
ppcc has been modified for Sun's C++ 4.x.