http://www.bell-labs.com/project/nmake/newsletters/
Patch level 1 for lu3.6 was released in September. The patch overlays lu3.6. Installation is automated and includes an option to back-out the patch and restore your nmake installation to its previous state. For details see the lu3.6-p01 patch page.
The following files are affected:
Here is a summary of the lu3.6-p01 fixes:
The JavaDeps update release JavaDeps-lu2.1.1 coincides with the lu3.6-p01 patch release. JavaDeps is an optional package and only required for projects building Java code using the nmake supplied :JAVA: operator. Although the JavaDeps update does not require the lu3.6 patch, there are some java related fixes in the lu3.6 patch so we recommend upgrading both for projects currently using nmake with JavaDeps. For details see the JavaDeps and lu3.6-p01 pages.
JavaDeps lu2.1.1 includes the following fixes:
nmake for Windows® 2000 is currently in beta and will soon be available as a pre-release to our current customers. This port uses UWIN which is a commercial UNIX-like porting and development environment for Microsoft® Windows®. For more details see the nmake/UWIN Introductory Release page and the release notes.
If you are interested in trying the beta or pre-release package you can download the package and contact us for a license key. We are making the keys available for the beta and pre-release phases free of charge to existing customers. We appreciate all the feedback we can get during these phases.
In issue 4 we discussed rules for using
the proc compiler. As originally written, the rules did not make
use of state variables to generate -D define flags. The rules
shown in issue 4 have been updated to handle this feature. The original
rules were using the default .SCAN.F scan strategy, which does
not enable the option to scan for candidate state variables. The updated
rules define a new scan strategy with this option enabled and then include
.SCAN.F for the rest of the definition.
.SCAN.proc : .SCAN O|S| $(@.SCAN.F) .ATTRIBUTE.%.pc : .SCAN.proc .SOURCE.%.SCAN.proc : .FORCE $$(*.SOURCE.pc) $$(*.SOURCE.h)
See the ProC article in issue 4 for the full set of rules.
We have noticed some versions of the Solaris C/C++ compilers do not
respect the umask when linking with the -g flag. In this
case the generated executable always has the execute bits set regardless
of the umask. Here is a simple example:
$ cc -V cc: Sun WorkShop 6 2000/06/19 C 5.1 Patch 109491-02 $ umask 133 $ cc -c hello.c $ cc -o hello hello.o $ ls -l hello -rw-r--r-- 1 nmake sablime 6724 Dec 3 14:28 hello $ cc -g -o hello hello.o $ ls -l hello -rwxr-xr-x 1 nmake sablime 180224 Dec 3 14:28 hello
Without the -g flag hello is generated with
the expected permissions. When -g is used all the execute
bits are set. This appears to be due to ild, the incremental
linker, which is invoked by the -g flag. The use of
ild can be avoided to get the expected permissions, but
we are unsure if this has any side affects.
$ cc -xildoff -g -o hello hello.o $ ls -l hello -rw-r--r-- 1 nmake sablime 6724 Dec 3 14:33 hello
For a deeper study use cc -# to run the compiler in verbose mode.
If this causes problems for your builds you can use :INSTALL:
or :INSTALLDIR: to explicitly set the permissions during
install operations.
$ cat Makefile CCFLAGS = -g $(BINDIR) :INSTALLDIR: hello mode=744 hello :: hello.c $ nmake install + cc -g -I- -D_TRACE_ -c hello.c + cc -g -o hello hello.o + cp hello ../bin/hello + chmod 744 ../bin/hello $ ls -l hello ../bin/hello -rwxr--r-- 1 nmake sablime 180224 Dec 3 14:43 ../bin/hello -rwxr-xr-x 1 nmake sablime 180224 Dec 3 14:43 hello
If for some reason the above is not sufficient, another option is to create a rule to change the mode after executable targets are linked.
$ cat Makefile
/*
** when using -g the sun compiler calls ild to link.
** idl does not set the permissions as expected,
** the following rule works around it.
*/
.COMMAND.o : .COMMAND.chmod
.COMMAND.chmod : .AFTER .REPEAT .FORCE .VIRTUAL
chmod 744 $(<<)
CCFLAGS = -g
:ALL:
hello :: hello.c
$ nmake
+ cc -g -I- -D_TRACE_ -c hello.c
+ cc -g -o hello hello.o
+ chmod 744 hello
$ ls -l hello
-rwxr--r-- 1 nmake sablime 180224 Dec 3 14:47 hello
In cases where a project uses a large, global header file included by all the application code, it may be desirable to not recompile everything when the header is touched, but rather only recompile the files affected by the change. If the global header only contains cpp definitions this can be done by defining a .PARAMETER file.
In the following example there are 3 source files, each file uses a unique
variable defined in foo.h (F1, F2,
F3.) The files are only recompiled when the value of
their corresponding variable is changed in foo.h.
$ cat Makefile
CC = /opt/exp/gnu/bin/gcc
.SCAN.parameters : .SCAN
D| \# define %|
foo.h : .PARAMETER .TERMINAL .IGNORE .SCAN.parameters .SPECIAL
CCFLAGS += -I$("foo.h":T=F:D)
:ALL: t1 t2 t3
$ cat t1.c
#include
#include "foo.h"
int main(){
printf("FOO - %s\n",F1);
return(0);
}
$ cat foo.h
#define F1 "foo"
#define F2 "foo"
#define F3 "foo"
$ nmake
+ /opt/exp/gnu/bin/gcc -O -I. -I- -o t1 t1.c
+ /opt/exp/gnu/bin/gcc -O -I. -I- -o t2 t2.c
+ /opt/exp/gnu/bin/gcc -O -I. -I- -o t3 t3.c
$ touch foo.h
$ nmake
Notice nothing rebuilds when foo.h is touched. Now we'll
change the value of F2 in foo.h. Only file
t2.c is recompiled since only it uses F2.
$ cat foo.h #define F1 "foo" #define F2 "foobar" #define F3 "foo" $ nmake + /opt/exp/gnu/bin/gcc -O -I. -I- -o t2 t2.c
This method can be used to reduce the impact of changes to such include
files during incremental builds.
The disadvantage of this method is that foo.h needs
.IGNORE so the files that include it do not recompile when
foo.h is touched. This also causes no -I
flag to be generated for it, so a -I flag must be manually
added to CCFLAGS as shown above.
<<home / newsletters