Nokia nmake Product Builder
Customer Support Newsletter

http://www.bell-labs.com/project/nmake/newsletters/

Issue No. 16 - December 2003
Contacts
Highlights
  1. Release lu3.6 Patch 1
  2. JavaDeps lu2.1.1
  3. Pre-release Windows 2000 Support
Technical Notes
  1. ProcC Metarule Update
  2. umask and the Solaris Compiler
Tidbits
  1. Parameter Files

Highlights

Release lu3.6 Patch 1

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:

index

JavaDeps 2.1.1

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:

index

Pre-Release Windows 2000 Support

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.

index


Technical Notes

ProC Metarule Update

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.

index

umask and the Solaris Compiler

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

index


Tidbits

Parameter Files

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.

index

<<home / newsletters