Released: June 2003
1.1 Supported Hardware
1.2 Hardware Requirements
1.3 Customer Support
2. New Features Introduced in Release lu3.6
2.1 Jar File Support
2.2 Batched concurrent Java builds now supported
2.3 Engine queue feature for batch compilations
3. Bug Fixes and Enhancements
4. Changes Impacting lu3.5 Makefiles
5. Known Problems and Remarks
5.1 Known Problems
This document announces the new release of nmake version lu3.6. nmake is fully supported and is in wide production use throughout Lucent Technologies, AT&T, and elsewhere.
These lu3.6 Release Notes discuss in detail the new features, highlights bug fixes, additional enhancements, and known problems.
The lu3.6 release has been ported to many UNIX-based systems. For a current list see the Availability Chart and the Download Page on the nmake web site, http://www.bell-labs.com/projects/nmake/. Or contact the Customer Support helpdesk below.
We provide patch support, where code changes are required, for nmake releases lu3.6 and lu3.5 (the latest two releases.) Customers using older releases can still acquire help in using the product, but genuine problems found in older releases will not be fixed. Such problems may require an upgrade to a current release or, when possible, a makefile work-around will be provided.
Fee-based services are also available. These include makefile rewrites, conversion of non-nmake makefiles to nmake, integration with vendor tools, build assessments, and porting nmake to new machines.
Contact Customer Support for any questions regarding nmake.
:JAR: assertion builds and maintains jar files, with
support for viewpathing, index files, and manifest files. Multiple
:JAR: assertions are supported in a single Makefile.
:JAR: operator has the format:
name.jar :JAR: [manifest-file][JARROOT=root_dir] files...
File prerequisites are specified using full ksh-style shell patterns allowing directories to be recursively searched for matching files. If a manifest file is specified its contents is merged to the target jar file as one part of the internal manifest file.
When using jdk1.2 or higher jar files are generated by stepping through the viewpath and adding the necessary files from each node to the jar file. Jar files are updated incrementally with the new or modified files. Since the older jar command does not support the update feature, compatibility with jdk1.1 is preserved by using a temporary directory to collect the files from each node in the viewpath and generating the jar target file from the temporary directory.
The following example picks up all the
*.png files recursively under the
manifest.mf will be merged with the
internal manifest file. All the files in the jar will be specified
classes as defined by
$ cat jar.mk JARROOT = classes stc.jar :JAR: manifest.mf classes/*.(class|png) $ nmake -f jar.mk -- Making stc.jar -- + cd /home/richb/v2/classes + jar cf /home/richb/v1/stc.jar com/lucent/stc/C.class com/lucent/stc/im ages/logo.png + cd /home/richb/v1/classes + jar uf /home/richb/v1/stc.jar com/stc/A.class com/stc/B.class + jar umf /home/richb/v2/manifest.mf /home/richb/v1/stc.jar + jar i /home/richb/v1/stc.jar $ jar tvf stc.jar 98 Wed May 07 18:16:46 EDT 2003 META-INF/INDEX.LIST 0 Wed May 07 18:16:42 EDT 2003 META-INF/ 57 Wed May 07 18:16:44 EDT 2003 META-INF/MANIFEST.MF 0 Wed May 07 18:12:04 EDT 2003 com/lucent/stc/C.class 0 Wed May 07 18:12:40 EDT 2003 com/lucent/stc/images/logo.png 0 Wed May 07 10:18:26 EDT 2003 com/stc/A.class 0 Wed May 07 10:17:30 EDT 2003 com/stc/B.class
At this time the
cannot be used in the same makefile for building classes and generating
the corresponding jar file. Please see the man page,
included with the nmake package, for full details and options
for using the new
:JAR: operator has a different usage than the
jar rules from our newsletter.
Some makefile changes will be necessary if you are migrating to the new
See Changes Impacting lu3.4 Makefiles: Jar File Support for details.
Java files are optionally compiled in batches to minimize expensive
calls to javac. This performance enhancement feature is called
batched compilation. However, in previous releases, batched
compilation could not be used together with another performance
enhancing feature, concurrent compilation. In this release, batched
concurrent builds are now supported. This is enabled simply by
-j option. The following example will run up to
5 jobs concurrently while batching 10 java source files per compile.
$ nmake maxjavac=10 -j5 -f java.mk
.BATCH have been added to support batch
compilation. These special atoms are used in conjunction to allow safe
concurrent builds for batched file generation.
.BATCHis a dynmaic attribute used to mark jobs which compile a batch of files.
.BATCHEDis a dynamic attribute used to mark targets that are collected for batch compilation. When set it indicates the target has not been created and is just a false file. Targets that have
.BATCHEDprerequisites are blocked.
.BATCHis a dynamic list which contains the queued targets for batch job target. When a
.BATCHjob completes, nmake clears the
.BATCHattribute for target and clears the
.BATCHEDattribute for each prerequisite of target
.BATCH, which allows the blocked dependent jobs on the queue to run.
globaljavadepscan be redefined using the
GLOBALJAVADEPSvariable. The default is
JAVACFLAGSvariable no longer defaults to
-O, there is no default value now. The Sun jdk1.3 man page for javac(1) indicates the
-Oflag does nothing, and the flag is completely absent from the jdk1.4 man page. If you still want to compile with
-Oyou must define
::) operator, the warning message issued if the target library name does not begin with "
lib" can now be suppressed by setting variable
sharedlib_name_warningto null. Also note the variable name was changed from
java_warp_fileallows a convenient shorthand for target paths specified on the command line.
java_warp_targetspecifies an edit operation that selects local targets to be ``warped'' to their corresponding location under
JAVACLASSDEST. By default
java_warp_fileis null. Set
java_warp_file=N=*.classto warp class file targets. The following example of a local package build shows the target
B.class, specified on the original command line, being warped to
$ nmake B.class /home/richb/work/src + nmake classdir/java/p53/B.class -f 020053.mk javasdir=java/p53 ja varhs=*.java javaclassdest=../../classdir + javac -d classdir -classpath classdir:. java/p53/B.java
:cc:in conjunction with
:COMMAND:, the variable set by
:COMMAND:would sometimes expand to null when it should have some value. This has been fixed.
-Iflags from prefixinclude
-I-nmake would generate redundant
-Iflags on the compile lines. Under certain conditions nmake could also specify
-Iflags in the wrong order of the viewpath. Both problems are fixed.
javadepsvariable was initialized in JAVA.mk in such a way that setting
javadepsin a makefile was ignored, it only worked when set on the command line. Defining
javadepsin the makefile now works.
.mofile, which caused new java source files to not be compiled in incremental builds. JAVA.mk now builds the list of java files at run time so new source files are picked up and compiled when
lineid, has been added which corresponds with the
-D-Lflag to specify the line number control output directive. The usage is:
#pragma lineid line-directive
-gflag to reference a compiled global makefile that contains metarules, nmake would not build the targets in the makefile. This is fixed.
-SCANNEDwill now clear the cache for the specified directories.
$(*)variable would include the filename of the missing file when the
-F(force) flag was used but not when
-Fwas not used. The behavior is now consistent both when forced and not forced, and
$(*)does not expand the secondary pattern prerequisite if a matching file does not exist.
$(>)variable will now expand the primary prerequisite plus the out of date secondary prerequisites. Previously
$(>)failed to expand any secondary prerequisites.
:T=Fvariable edit operator would not expand relative directories specified with a slash (
/) at the end. This has been fixed and such directories are expanded if they exist.
&=) and no primary value would get the auxiliary value expanded on the first nmake run, but subsequent incremental builds would expand the variable to null. Now the auxiliary value is always expanded if it is defined regardless of the primary value.
:JAVA:assertion. The problem was caused by the expansion of the
.SOURCE.classatom which contained the prerequisite .jar files. A new special atom has been introduced,
.NOCROSSPRODUCT.%., which suppresses the cross product expansion of
%.<pattern>files in the specified
.SOURCE.special atom while still giving us the first occurrence of %.<pattern> in the viewpath. The following is predefined in the base rules:
.SOURCE.class : .NOCROSSPRODUCT.%.jar .NOCROSSPRODUCT.%.zip
.ACTIONWRAPcould not handle
.MAKEimmediate rules and would generate an error from ksh trying to execute
.MAKErules are now handled properly by
.ACTIONWRAPand thus work with nmakelog.
$(*)variable would not expand through the viewpath when the target of the rule was an archive library. This could cause locally defined archive rules to fail when updating in the viewpath. This now works and
$(*)is expanded through the viewpath for archive targets.
.BATCHEDwere introduced to support this.
.IMMEDIATEon the lhs) will now trigger their action blocks as well as making their prerequisites.
:cc:operator will no longer cause targets of
:LIBRARY:to reinstall when they have not changed.
CC.SUFFIX.SHAREDcan now be used to define shared library targets with the
::operator to produce platform independent makefiles. For example, the following will make
libabc.soon Solaris and
libabc$$(CC.SUFFIX.SHARED) :: a.c
CC.REPOSITORYis no longer set for compilers that do not use the
-ptrflag to refer to the repository directory. This eliminates unnecessary
-ptrflags from the compile line for such compilers.
ld. With C++ code this would sometimes result in unusable libraries. The compiler is now used for linking shared libraries and executables when the compiler supports it. In this case the probe variable
CC.LDis set to the compiler instead of the
--prelink_copy_if_nonlocalfor setting the
CC.PRELINKvariable. In the past it could be set for some compiler that didn't support the flag causing errors when compiling.
/usrto be searched for include files. Probe will now detect when
/usris required and include it in the default standard include directories.
lineidpragma when necessary. See also 020076.
GLOBALJAVADEPS- see 020036.
JAVACFLAGSdefault changed - see 020037.
sharedlib_name_warning- see 020040.
java_warp_target- see 020053.
$(*)- see 010034, 020050.
$(>)- see 010035.
The changes in release lu3.6 are largely backward compatible with lu3.5. Every effort has been made to insure code changes do not unexpectedly change the documented behavior of nmake features.
The following enhancements required small changes to functionality as described below.
:JAR:assertion operator is new in release lu3.6. However, some folks may be using our preliminary jar support rules published in our newsletter. The lu3.6
:JAR:assertion has a different usage from the rules published in the newsletter. The prerequisite can no longer be directory name, it must be a shell pattern to determine the files to pick up. Consequently the
JARTYPESvariable is depreciated since it is no longer needed. Also, support for a manifest file prerequisite has been added.
:JAR:assertion. Those who do not wish to migrate can continue using the old jar rules, your local jar rules will override the default rules.
/* old jar rules assertion */ file.jar :JAR: classes JARROOT=classes JARTYPES=.class|.jpgThe above assertion using the old rules can be rewritten as:
/* lu3.6 assertion */ file.jar :JAR: classes/*.class classes/*.jpg JARROOT=classesOr further simplified as:
/* lu3.6 assertion */ file.jar :JAR: classes/*.(class|jpg) JARROOT=classes
The following is a list of known problems:
CC.REPOSITORYis defined, and
::is used to trigger the metarule. Note that
CC.REPOSITORYis defined automatically for some C++ compilers in the probe file. The work-around is to add
::assertion, or to not use the
::assertion (such as add the target to
arcleanvariable is defined. The shared object files are typically recompiled and re-archive every other build.
localprobe=vpath. This can happen when the probe file is moved from one viewpath node to another node, or when adding a new, empty node to the front of the viewpath and the viewpath root nodes differ by more than one directory level at the end of their paths (for example,
VPATH=/build/x1:/build/y1will not rebuild, but
-xar(such as Sun's Solaris C++ compiler) and using the
::operator to build a shared library, the library will be generated with the object file prerequisites from all
::assertions in the makefile. This may result in link errors or the library containing more code than intended.
%.c, the first metarule defined will be triggered instead of the metarule matching the file prerequisite suffix.
#include "file.h") incremental builds may have compilation errors due to missing
-Iflags on the compile line. The work-around is to use consistent directory prefixes in the include statements. Re-ordering the source code in the makefile may also cure the problem.
-Iflags are omitted from the compile line. This has been observed when a rule triggered from
.INITcopies header files to some directory, the header copies are #included by source code in the same makefile, and
prefixinclude=1. The work-around is to disable prefixinclude by setting