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
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
and let us know how it goes.
Follow these steps to install SGE support. These instructions assume you already have a working nmake lu3.8 installation.
- Save sge_Makerules.mk
- Copy or move sge_Makerules.mk to <nmake_lu3.8_root>/lib/make/sge_Makerules.mk
- Change directory to <nmake_lu3.8_root>/lib/make/
- Compile the new rules:
nmake -bcf sge_Makerules.mk
- Save your original makerules.mo:
mv makerules.mo makerules.mo-orig
- Install your new makerules.mo:
mv sge_Makerules.mo makerules.mo
To revert the installation restore your original makerules.mo:
mv makerules.mo-orig makerules.mo
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
script. To enable SGE support in nmake set
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.
sge_qrsh=1to enable SGE support (default '0')
QRSH- the qrsh command (default '
QRSHFLAGS- qrsh command flags (default '
-cwd -noshell -V')
SGESHELL- the shell to use (default is
kshin that order of precedence)
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:
- Description of basic project setup for use with nmake.
- Downloadable sample project demonstrating basic framework for multi-directory recursive build.
- Initial version of a downloadable add-on nmake rules file designed to better adapt nmake build output to the format expected by the CDT error parser.
- Description of use of the Eclipse CDT Make Targets View with nmake build targets.
- List of current integration issues.
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.
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.
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
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