Alcatel-Lucent nmake: lu3.8 Release Notes (New Features)

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.

2.2 Improved support for Sun C++ 7.x and 8.x compilers

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.

2.3 :JAVA: performance enhancements

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 maxjavawarn 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 set the maxjavawarn variable to emphasize either performance or the warning notice. Also see the :JAVA: manual page for information on maxjavawarn.

2.4 Support for Java builds from a directory other than the source package directory

The :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

2.5 Java builds filter out #empty files

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.

The :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.

The :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 makefile:

.ATTRIBUTE.%.class : .SCAN.java

See the :JAVA: and :JAR: manual pages for details.

2.6 globaljavadeps and localjavadeps are synchronized via the state file

Information for localjavadeps and globaljavadeps 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.

If globaljavadeps is touched or removed then it is regenerated from a full rescan of the Java source code.
If localjavadeps is touched or removed then it is regenerated from the existing globaljavadeps.
If JavaDeps fails in an incremental build then the next build will attempt to run JavaDeps again. Previously when JavaDeps failed the source files in the incremental scan appeared up to date in the subsequent build so JavaDeps was not re-run.

2.7 MS Visual C++ compiler supported on Windows/SFU

The Microsoft Visual C++ compiler is now supported on the Windows/SFU (Services for Unix/Interix) platform using the Interix /bin/cc compiler wrapper. The wrapper and environment must be configured according to Interix requirements.

2.8 New environment variable UMASKCHANGE to disable umask change

The disableumaskchange option name and -u command 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. UMASKCHANGE 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 other UMASKCHANGE value generates a warning and keeps the umask change enabled.

2.9 nmakelog now compatible with :JAR: makefiles

The nmakelog output serializer is now compatible with :JAR: makefiles.

2.10 Enhanced manifest file support for :JAR:

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.

2.11 Multiple :JAR: makefiles can update the same target jar file

Multiple :JAR: makefiles can update the same target jar file by setting the new nmake variable jarappend=1. 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.

[Table of Contents] [Previous Section] [Next Section]

Last Update: Wednesday,20-Dec-06 13:22:12 CST