July 2007
[Table of Contents]
[Previous Section]
[Next Section]
This feature allows job action blocks to be piped to a job distribution
utility such as the Sun Grid qrsh. Each triggered action
block is piped to a separate invocation of qrsh or other
distribution utility. No makefile changes are needed, the feature works
for arbitrary existing makefiles. The build log serialization feature
has also been extended to support concurrently executing jobs arising
from this feature. Currently, all regular shell jobs are spun off without
regard to the .LOCAL attribute.
The following variables are used to control the feature:
sge_qrsh=1.
Default: sge_qrsh = 0
QRSH = qrsh
QRSHFLAGS += -cwd -noshell -V
SGESHELL := $(SGESHELL|COSHELL|SHELL|"ksh")
A new recurse message customization feature allows nmake to be integrated with Eclipse CDT. Eclipse CDT is an Eclipse-based IDE for C and C++ development. The new feature is capable of emulating GNU make recurse messages. The approach has the additional advantage that it also allows interoperability with other compilation error tracking tools such as GNU Emacs compilation mode. The feature design has the advantages that it works for any recursive nmake invocation, not just :MAKE:/:CC:, supports reporting of make numeric recursion levels, and is completely automatic, no special nmake options need be added by the user to get it to work. The approach is backward compatible and should work with arbitrary existing Makefiles.
For help setting up Eclipse CDT to use nmake see the
Eclipse CDT Support page on the
nmake web site at
http://www.bell-labs.com/project/nmake/manual/eclipsecdt.html.
The provided eclipserules.mk file is not needed when using
nmake alu3.9. Instead just set recurse_begin_message=gnu to
configure the proper recurse messages.
The details of the new recurse message feature are as follows.
recurse_begin_message and
recurse_end_message allow customization of
the format and content of messages output at entry and exit of
recursive nmake invocations; in addition recurse_begin_message
may now take 2 special keyword values:
recurse_begin_message = default
recurse_begin_message = gnu
Setting recurse_begin_message to "default" provides backward
compatible nmake recurse messages. This prints the target directory/file
before recursion and nothing after recursion. The default messages are
output only for baserules provided recursion facilities such as :MAKE:.
This is the default setting for recurse_begin_message.
Setting recurse_begin_message to "gnu" provides GNU make
compatible recurse messages. These messages emulate gnu make recurse
messages and contain the current recursion level and target directory.
This format is especially useful when using nmake with development tools
that already understand the GNU recurse message formats. These development
tools typically use recurse messages to track the current directory in
recursive builds, allowing the tool to perform automatic mapping of
compilation errors to the source file and line containing the error.
Examples of such tools are the Eclipse CDT C/C++ IDE and GNU Emacs
compilation mode.
If recurse_begin_message is not one of the reserved keywords,
recurse_begin_message and recurse_end_message
specify customized messages. In this case nmake prints the expanded value
of recurse_begin_message when it starts up and the expanded
value of recurse_begin_message when it exits.
gnu style and customized messages are automatically output for all
recursive nmake invocations, not just invocations initiated using
baserules assertions such as :MAKE:. This output is automatic and
does not require any special setup in user Makefiles. If desired,
this behavior may be suppressed by resetting recurse_begin_message
on the recursive nmake command line. Setting
recurse_begin_message and recurse_end_message
to null completely suppresses all recurse messages.
For current information on using Eclipse CDT, JDT and more, check the Eclipse Support page on the nmake web site at http://www.bell-labs.com/project/nmake/manual/eclipsesupport.html.
Sun JDK 6 (1.6.0) has been certified with nmake alu3.9.
The license key parser is no longer sensitive to white space making maintenance and installation of key files easier. The parser does the following to avoid common sources of invalid license errors that occur when installing keys.
A performance bottleneck was identified in the :JAVA: and :JAR: support and a rule has been rewritten to improve the performance. It will be most noticeable for large Java packages. The following benchmarks measure the time the affected rule spent processing the list of files in the java package, not the entire compilation or archiving time. The old rule took about 1 hour and 28 minutes to process a package of 45000 files. The new rule processes the same set of files in about 18 seconds. The improvement is also noticed using a more reasonably sized package of about 3000 files. The old rule took about 22 seconds to process the 3000 file package where the new rule takes about 1 second.
The maxjavawarn
baserule variable introduced in lu3.8 is no longer needed and has
been removed.
The new variable edit operator :P=VL has been added to the engine. :P=VL returns the view local path name for each token that is an atom bound to a file. Paths in the viewpath are canonicalized and converted to their corresponding relative local path. Paths outside the viewpath are returned unmodified. Unbound paths return null.
For the following example assume these values:
VPATH = /v1:/v2:/v3 PWD = /v1/src/abc
| Variable | Expanded Value |
|---|---|
| $("/v2/src/file1":P=VL) | ../file1 |
| $("../../src/file1":P=VL) | ../file1 |
| $("/v3/include/hdr.h":P=VL) | ../../include/hdr.1 |
nmake can now run on Windows XP SP2 as configured by default. Previously it could not run if Data Execution Prevention (DEP) was enabled which is the default in SP2.
This release fixes -I compiler flag generation for several
corner cases. The problems caused -I
flags to be omitted from compile lines leading to build errors.
Most of the problems came when using the native preprocessor
which is the default for popular compilers such as Sun Studio
Compilers, HP aCC and gcc/g++. These fixes provide for more
robust builds.
[Table of Contents] [Previous Section] [Next Section]