Release lu3.8 has been officially tested and verified on two additional platforms, Solaris 10 (sometimes referred to as 2.10) and Red Hat Enterprise Linux 3.
Support for Sun's SUNWCCh include rule has been enhanced and better supports
the 7.x and 8.x compilers. The probe variable
CC.SUFFIX.LINKHEADER has been added to list the system headers
with versions ending with SUNWCCh so nmake can bind and scan the proper
headers when scanning source code. Headers that are rewritten with
the SUNWCCh rules are also now retained in the state file so they are
known for subsequent builds.
The Java rules have been optimized for the common case resulting in a significant performance improvement when processing large Java packages. Before the optimization a particular operation in the Java rules was observed to take about 24 minutes for a Java package of about 18,000 Java source files. After optimization this operation was actually eliminated for the common build resulting in a drastic reduction in time for processing the package.
A second optimization is user controllable using the
base rule variable. The variable contains the maximum number of Java
source files in a Java package in order to determine and warn of source
files that have been removed in an incremental build. The default is
maxjavawarn=3000 meaning a Java package of 3000 or less
source files will warn the user when Java source files are removed in
an incremental build (since their old classes may still exist). The
check is skipped and no warning issued if there are more than 3000 source
files in the package. The package of 18,000 source files mentioned above
took approximately 15 minutes to check for deleted files. Projects can
maxjavawarn variable to emphasize either performance
or the warning notice. Also see the
:JAVA: manual page for information
:JAVA operator now supports building Java code where
the package root is in a different directory from the makefile and
.SOURCE.java is used to locate the package root. Here is
an example makefile:
/**** obj/Makefile ****/ JAVABUILDDIR = $(VROOT)/obj JAVAPACKAGEROOT = $(VROOT)/java .SOURCE.java : $(JAVAPACKAGEROOT) :JAVA: com
Since 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. However, in a viewpathing situation where versions of the deleted file remain in other viewpathed nodes, those unwanted versions will still be picked up. The #empty feature provides a way to remove a Java file from a build and also mask out viewpathed files in other nodes.
:JAVA: operator will filter Java source files
containing the string "#empty" out of the build. The contents of
a source file can be changed to "#empty", masking out old versions
of the file in the viewpath, when it should no longer be built.
Source files changed to "#empty" in an incremental build will have the
contents of their class files changed to "#empty" effectively removing
the class and masking out old versions in the viewpath.
:JAR: operator will also exclude Java source files
containing the string "#empty" when creating a jar archive of source
files. By default class files are not scanned nor filtered to eliminate
any performance impact for projects not using the feature. Class files
can be filtered from jar archives by including the following in the
.ATTRIBUTE.%.class : .SCAN.java
are now stored in the state file. If either file changes or is removed
outside of nmake the file will be automatically regenerated to return it
to a trusted state.
globaljavadepsis touched or removed then it is regenerated from a full rescan of the Java source code.
localjavadepsis touched or removed then it is regenerated from the existing
The Microsoft Visual C++ compiler is now supported on the Windows/SFU
(Services for Unix/Interix) platform using the Interix
compiler wrapper. The wrapper and environment must be configured
according to Interix requirements.
disableumaskchange option name and
line option have been removed and replaced with the environment variable
UMASKCHANGE. The change is due to the need to set the umask
early in nmake startup before the options are read.
must be set in the environment not in the makefiles.
UMASKCHANGE may be 0/NO/no to suppress changing the umask to
match the current directory permissions, or 1/YES/yes/null to change the
umask. For compatibility the umask change is enabled by default. Any
UMASKCHANGE value generates a warning and keeps the
umask change enabled.
nmakelog output serializer is now compatible with
The manifest file in a
:JAR: assertion now triggers updates
when the manifest file is touched or when a different manifest file is
specified. If multiple manifest prerequisites are specified the first
one is used and others are ignored with a warning message.
:JAR: makefiles can update the same target jar
file by setting the new nmake variable
By default the jar target is recreated by each makefile thereby
losing the archive members from the previous makefile. Set
jarappend=1 in the makefile to add members to an
existing jar without losing its contents.