Nokia nmake Product Builder
Customer Support Newsletter

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

Issue No. 24 - January 2007
Contacts
Articles
  1. Sun Grid Support
  2. Eclipse IDE Support
  3. probe Shell Support
  4. #empty Java Files

Sun Grid Support

We have preliminary support for running distributed nmake builds over Sun Grid Engine (SGE) using nmake lu3.8. Support is implemented in a modified Makerules.mk which uses qrsh to submit jobs to SGE. There are no changes to the nmake engine. Projects already using SGE may prefer SGE to coshell for distributed builds for ease of maintenance and possibly improved performance. SGE support may be included in a future nmake release if feedback is positive. If you try it, drop us a note at nmake@alcatel-lucent.com and let us know how it goes.

Installation

Follow these steps to install SGE support. These instructions assume you already have a working nmake lu3.8 installation.

  1. Save sge_Makerules.mk
  2. Copy or move sge_Makerules.mk to <nmake_lu3.8_root>/lib/make/sge_Makerules.mk
  3. Change directory to <nmake_lu3.8_root>/lib/make/
  4. Compile the new rules: nmake -bcf sge_Makerules.mk
  5. Save your original makerules.mo: mv makerules.mo makerules.mo-orig
  6. Install your new makerules.mo: mv sge_Makerules.mo makerules.mo

To revert the installation restore your original makerules.mo:

  1. mv makerules.mo-orig makerules.mo

Usage

We assume your environment is already setup for using SGE and qrsh is in your PATH. So first setup your environment as you typically would for SGE, for example with the SGE settings.sh script. To enable SGE support in nmake set sge_qrsh=1 in your makefile, on the nmake command line, or exported in your environment.

SGE support uses the following nmake variables. Typically only sge_qrsh needs to be set by the user.

index

Eclipse IDE Support

Eclipse is a widely used, multi-platform IDE (Integrated Development Environment) providing a rich development environment for Java, C/C++, and many other languages and tools. Eclipse itself is organized as an open source project and the Eclipse tool is freely available as a download from the www.eclipse.org web site. Eclipse is also available in Alcatel-Lucent exptools, so it may be already available on your development host if you are an exptools subscriber.

Effective use of Eclipse for nmake-based projects is currently possible. Depending on the languages and Eclipse plug-ins involved, many nmake/Eclipse usage scenarios are possible. C/C++ developers will be especially interested in CDT, Eclipse's C/C++ development environment.

A new "how-to" document describing basic project setup of Eclipse CDT for use with nmake-based projects is now available. Projects set up following the documented procedures provide essential integrated nmake-based build functionality from within Eclipse CDT including directory local builds, global project builds, and correct mapping from build compilation errors back to source locations even in multi-level builds. The initial version of the Eclipse set-up document includes:

index

probe Shell Support

In nmake releases lu3.5 through lu3.8 the probe shell scripts only support ksh. Using another login shell, such as bash, may result in probe errors with probe variables set incorrectly. For release lu3.9 the probe scripts will support ksh and bash, /bin/sh will not be targeted. However, if the scripts are run with an incompatible shell they will attempt to re-launch themselves with ksh or bash.

index

#empty Java Files

Release lu3.8 added support for filtering #empty files in Java builds. Because Java source files are not typically listed in the makefile they cannot simply be removed from the makefile to be removed from the build. Deleting a Java source file will eliminate that file from a build, but in a viewpathing environment old versions of the file will still be built from other viewpath nodes. The #empty feature provides a way to remove a Java file from a build and mask out viewpathed versions in other nodes.

The :JAVA: operator will filter Java source files containing the string "#empty" out of the build. Source files changed to "#empty" in an incremental build will have the contents of their class files changed to "#empty" to mask out old versions of the class in the viewpath.

Java Example

Here is an example build. In the initial build everything is in the ofcl node. Only the d.java file contains #empty.

$ find . -type f -print    
./ofcl/java/com/a.java
./ofcl/java/com/b.java
./ofcl/java/com/c.java
./ofcl/java/com/d.java
./ofcl/java/Makefile

$ cd ofcl/java

$ echo $VPATH
/home/richb/bld/ofcl

$ cat Makefile
JAVAPACKAGEROOT = $(VROOT)/java
:JAVA: com

$ ls -l com
total 12
-rw-r--r-- 1 richb richb 83 Dec 21 14:52 a.java
-rw-r--r-- 1 richb richb 83 Dec 21 14:52 b.java
-rw-r--r-- 1 richb richb 83 Dec 21 14:52 c.java
-rw-r--r-- 1 richb richb  7 Dec 21 15:09 d.java

$ cat com/d.java
#empty

$ nmake
make: #empty java files: com/d.java
+ /tools/nmake/javadeps/jdeps /tools/nmake/javadeps/jdeps.jar -C .JAVACLASS
ES. -n --vpath=/home/richb/bld/ofcl --silent -s /tools/nmake/javadeps/synco
nfig -o localjavadeps -m globaljavadeps -d ../java --classpath=../java com/
a.java com/b.java com/c.java
+ javac -d ../java -classpath ../java:. com/c.java com/b.java com/a.java

$ ls -l com
total 24
-rw-r--r-- 1 richb richb 226 Dec 21 15:11 a.class
-rw-r--r-- 1 richb richb  83 Dec 21 14:52 a.java
-rw-r--r-- 1 richb richb 226 Dec 21 15:11 b.class
-rw-r--r-- 1 richb richb  83 Dec 21 14:52 b.java
-rw-r--r-- 1 richb richb 226 Dec 21 15:11 c.class
-rw-r--r-- 1 richb richb  83 Dec 21 14:52 c.java
-rw-r--r-- 1 richb richb   7 Dec 21 15:09 d.java

Notice d.java was not compiled. Next we'll build in the patch1 node using a viewpath of patch1:ofcl.

$ cd ../../patch1/java

$ echo $VPATH
/home/richb/bld/patch1:/home/richb/bld/ofcl

$ nmake

Nothing rebuilt because everything is up to date. Now let's remove a.java from the build.

$ echo "#empty" > com/a.java

$ ls -l com
total 0
-rw-r--r-- 1 richb richb 7 Dec 21 15:15 a.java

$ nmake
make: #empty java files: com/a.java

$ ls -l com
total 0
-rw-r--r-- 1 richb richb 7 Dec 21 15:15 a.class
-rw-r--r-- 1 richb richb 7 Dec 21 15:15 a.java

$ cat com/a.class
#empty

What happens if we restore a.java and empty b.java?

$ ls -l com
total 0
-rw-r--r-- 1 richb richb 7 Dec 21 15:15 a.class
-rw-r--r-- 1 richb richb 7 Dec 21 15:15 a.java

$ cp ../../ofcl/java/com/a.java com/

$ echo "#empty" > com/b.java

$ ls -l com
total 4
-rw-r--r-- 1 richb richb  7 Dec 21 15:15 a.class
-rw-r--r-- 1 richb richb 83 Dec 21 15:18 a.java
-rw-r--r-- 1 richb richb  7 Dec 21 15:18 b.java

$ nmake
make: #empty java files: com/b.java
+ javac -d ../java -classpath ../java:/home/richb/bld/ofcl/java:. com/a.java

$ ls -l com
total 8
-rw-r--r-- 1 richb richb 226 Dec 21 15:18 a.class
-rw-r--r-- 1 richb richb  83 Dec 21 15:18 a.java
-rw-r--r-- 1 richb richb   7 Dec 21 15:18 b.class
-rw-r--r-- 1 richb richb   7 Dec 21 15:18 b.java

$ cat com/b.class
#empty

Jar Example

It is also possible to filter #empty class files for jar targets but this is not enabled by default to prevent nmake from scanning all the class files for projects not using the feature. To enable the feature assign the Java scanrule to .class files as shown below.

Continuing the above example b.class contains #empty.

$ cat jar.mk
.ATTRIBUTE.%.class : .SCAN.java
abc.jar :JAR: com/*.class

$ nmake -f jar.mk
+ cd /home/richb/bld/ofcl/java
+ jar cf /home/richb/bld/patch1/java/abc.jar com/c.class
+ cd /home/richb/bld/patch1/java
+ jar uf /home/richb/bld/patch1/java/abc.jar com/a.class
+ cd .
+ jar i abc.jar

$ jar tvf abc.jar
    36 Thu Dec 21 15:27:50 EST 2006 META-INF/INDEX.LIST
     0 Thu Dec 21 15:27:48 EST 2006 META-INF/
    68 Thu Dec 21 15:27:48 EST 2006 META-INF/MANIFEST.MF
   226 Thu Dec 21 15:11:32 EST 2006 com/c.class
   226 Thu Dec 21 15:18:56 EST 2006 com/a.class

index

<<home / newsletters