Released: June 2002
1.1 Supported Hardware
1.2 Customer Support
2. New Features Introduced in Release lu3.5
2.1 Java inside-package local build
2.2 :: operator support for building shared libraries
2.4 IDL scan rule
2.5 Multiple language support for -I-
2.6 Prefixinclude for native preprocessors
2.7 Global version stamp in all binary executables
3. Bug Fixes and Enhancements
4. Changes Impacting lu3.4 Makefiles
5. Known Problems and Remarks
5.1 Known Problems
This document announces the new release of nmake version lu3.5. nmake is fully supported and is in wide production use throughout Lucent Technologies, AT&T, and elsewhere.
These lu3.5 Release Notes discuss in detail the new features, highlights bug fixes, additional enhancements, and known problems.
The lu3.5 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.5 and lu3.4 (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.
The inside-package build feature allows developers to launch builds from within a Java package, rather than only the package root. There are several motivations for this feature:
The introduction of the Java inside-package build feature changes the
:JAVA: operator so the variable
JAVAPACKAGEROOT is mandatory and must be defined.
JAVAPACKAGEROOT is normally the root directory of the Java
source tree and contains the top level Makefile for building the entire
Java tree. It is typically specified in the global makefile in the
See the :JAVA: man page for details
and examples. The man page is named
doc/jman.html in the
nmake lu3.5 package.
See also Changes impacting lu3.4 Makefiles: Java inside-package local build.
:: operator now supports shared library targets.
At this time the use of
$(CC.SUFFIX.SHARED) in the
target name is not supported. For portable makefiles across platforms,
where shared libraries may have different suffixes, continue using
Warnings are emitted if a shared library is built without the necessary
PIC flag (defined by variable
CC.PIC), or if
a shared library target name does not begin with "
Both of these cases may lead to problems linking with the library
or cause an inefficient library, depending on the platform.
CCFLAGS += $$(CC.PIC) libabc.so :: abc.c $ nmake + cc -O -KPIC -I- -c abc.c + ld -G -o libabc.so abc.o
The new quoteinclude feature allows the integration of tools that do
-I- for referencing include files in the viewpath.
quoteinclude=[1|2|3], nmake will emit a warning or
error when a
#include "..." directive is detected inside the
viewpath and the viewpath contains more than one node. The error is issued
with a severity level of the value of
severity level matches the level specified in the nmake
The quoteinclude feature is useful for projects using compilation
tools whose native preprocessor does not support the
and that for some reason cannot preprocess using the nmake supplied
preprocessor (such as versions of Iona's IDL compiler prior to Orbix 2000.)
Using quoteinclude, a project can effectively enforce the exclusive
#include <...> directives, which do not require
-I- for viewpath support. This allows projects to make full
use of viewpathing, while using compilation tool chains which do not
$(quoteinclude) is null and no errors are issued.
$ nmake quoteinclude=1 make: warning: hello.c uses quoted include for hello.h + cc -O -KPIC -I. -I- -c hello.c + cc -O -KPIC -o hello hello.o
A scan rule for IDL code, called
.SCAN.idl, is now defined
in the base rules. IDL files are scanned for file prerequisites and
candidate state variable references. Files ending with suffix
.idl will be scanned automatically. IDL files named with
another suffix must be associated with the scan rule as shown below.
.ATTRIBUTE.%.suffix : .SCAN.idl
.SOURCE.idl atom is used to define search directories
.idl files, including include files. The
flags generated from the scan can be inserted into a variable as follows.
IDLFLAGS &= $$(.INCLUDE. idl -I -I-)
There is no default build rule for IDL files due to variations in IDL compilers and their use by different projects. For details on using the IDL scan rule and building IDL code see the IDL FAQ on the nmake web site.
A framework is now in place to support the scanning of multiple languages
-I- support. This includes a new, generalized
.INCLUDE. function which generates include file search
The optional third argument to
.INCLUDE. specifies the
-I- style flag used by the compile tool. When present,
.INCLUDE. will return a list of search flags designed for
-I- support, with the third argument separating the local
include directories from the standard include directories in the search
list. The default behavior of
.INCLUDE. remains unchanged
when the third argument is omitted.
Use the following to generate the
for custom scan rules whose compile tools support
xxFLAGS &= $$(.INCLUDE. <lang> -I -I-)
The prefixinclude feature
now has support for native preprocessors. When using a native preprocessor
-I- but not prefixinclude, nmake will
add the necessary prefix directories to the
-I search list
on the compile command line to allow the native preprocessor to locate
the headers in these directories.
The following example shows
-Iinclude/abc added to the compile
line while only
include is part of the search directories
"abc/hello.h" which includes
"h2.h" (also under
abc/.) Note, when the nmake supplied preprocessor
-Iinclude/abc is not needed and is not added to the
.SOURCE.h : include hello :: hello.c $ nmake + cc -O -Iinclude -Iinclude/abc -I- -c hello.c + cc -O -o hello hello.o
All binary executables in the nmake package are stamped with the nmake version string. This identifies which release each executable belongs to. Either the what or ident commands can be used to show the version string.
$ what bin/nmake | grep make bin/nmake: Lucent(R) nmake (Bell Labs) lu3.5 06/07/2002 $ ident lib/cpp lib/cpp: $Id: nmake:cpp (Bell Labs) lu3.5 06/07/2002 $ $Info: build on: SunOS 5.4 (lion.stc.lucent.com) $
-I-but not prefixinclude, nmake will add necessary
-Iflags to the compile line so the preprocessor can find directory prefixed include files.
$(recurse_end_message)are now printed when recursing to a file. Previously, they were only printed when recursing to a directory.
$(RECURSE_MESSAGE). This added flexibility allows the recurse messages to be defined in the style of GNU make as shown below:
recurse_begin_message = make: Entering directory \`$PWD\' recurse_end_message = make: Leaving directory \`$PWD\'See also Changes impacting lu3.4 Makefiles: recurse messages enhancements.
.SYNCBEFORECCXtarget is now properly defined as a
.VIRTUALtarget in the base rules.
clobbercommon action would delete the current makefile. This has been fixed.
clobberignorecan be defined to prevent the specified files from being removed by the
clobbercommon action. For example, to prevent
libxyz.afrom being clobbered use
clobbercommon action is specified.
force_shared=0no longer turns on the force_shared feature.
force_shared=0will disable the feature if it was already enabled with
force_shared=1forces targets to relink when prerequisite shared libraries change.
CC.PRELINKis now specified on the compile line before the
-Iflags. This is to support EDG based C++ compilers which require the flags in this order.
-compat=4flag for Sun's C++ compiler as the cpp
-compatflag to preprocess code on compatibility mode. This results in incorrect preprocessing for the target compiler. To avoid conflicts such as this ppcc now strips offending flags from the command line when calling cpp and only includes the flags when calling the compiler. The change was put in ppcc instead of cpp itself to insure cpp retains compatibility with current usage.
__STDPP__macros to be undefined using the
-Uflag in compatibility and transition modes when the macros are defined by default . A warning message is issued when in transition mode. In strict ANSI mode the macros are read-only and an error is generated.
prefixinclude=0. This would cause the implicit prerequisite list to be incomplete and/or incorrect. This fixes the problem of scanning
:Fedit operator, which is used to format variable expansion, printed
%y(the short-hand year) as three digits instead of two. This would, for example, result in year
.JOINTrule was used to generate some files and its action block was attached to the rule (ie. no
.USErule), 2) A target of the
.JOINTrule matched the prerequisite of a metarule, and 3) The metarule had more than 1 target. Under these conditions nmake would run the
.JOINTaction to build the metarule targets resulting in an error.
.JOINTrule generated two files, file A and file B. The metarule generated file C from file A, and file B included file C.
installcommon action acted inconsistently depending on the order of the
:INSTALLDIR:assertions in the makefile. For example, assuming the assertions are installing to different target directories or file names, defining an
:INSTALLDIR:assertion followed by the corresponding
::assertion would result in a single install action. But defining the
::first and then
:INSTALLDIR:would result in two installs. Similarly, defining assertions in the order of
::could result in three installs, while
:INSTALL:would result in two. The assertions have been modified so the
::assertion will not trigger an install when its target is also installed by
:INSTALL:. The assertions now give consistent results regardless of their sequence in the makefile.
:LIBRARY:, shared library prerequisites were being left out of the library required file. Shared libraries are now included in the required file as expected. The required file is called
libnameand is installed to file
$(LIBDIR)/lib/name. When a target has a library prerequisite nmake reads the library's required file and automatically includes the listed libraries as prerequisites.
:ALL: alarm" in a makefile would cause nmake to try to build
.ALARMinstead of a valid target named
alarm. It is also fixed for targets named
:MAKE:operator to recurse to relative directories starting with
../. This worked in release lu3.3 but was broken in lu3.4.
/usr/include/bitsin the list of standard include directories. This causes errors when using nmake cpp because files should not be included directly from
/usr/include/bits, they should only be included by other standard include files. Probe no longer includes
/usr/include/bitsin the list of standard include directories.
CC.STDLIBwould contain one or more
../'s making them unnecessarily complex and difficult to read. The paths are now canonicalized, or simplified to remove occurrences of "
CC.SUFFIX.SHAREDvariable was incorrectly set to null for the Sun Solaris C++ 6u2 compiler. Probe now correctly detects the shared library suffix for this compiler.
clobberignore- see 010020
JAVACLASSDEST- see 020028
MAXJAVACdepreciated - see 020028
JDEPSDIR- see 020028
JAVAPACKAGEROOT- see New Features: Java inside-package local build
JAVACLASSDESTnow defaults to
MAXJAVACis deprecated, use
JDEPSDIRnow defaults to the first of the following directories that exists:
<nmake_install_root>/../javadeps <nmake_install_root>/../../javadepsSee also Changes impacting lu3.4 Makefiles: Java inside-package local build.
The changes in release lu3.5 are largely backward compatible with lu3.4. Every effort has been made to insure code changes do not unexpectedly change the documented behavior of nmake features.
A few enhancements did require small changes to functionality. These changes are described below.
installcommon action was inconsistent and dependent on the order of the
:INSTALLDIR:assertions in the makefile. The assertions have been modified to give consistent results regardless of their sequence. Now the
::assertion will not trigger an install when its target is also installed by
::assertion and either
:INSTALL:within the same makefile. We expect this to be very rare.
:INSTALLDIR:operation to replace the
recurse_end_messagevariables no longer print the current subdirectory by default. Prior to release lu3.5 the value of the variable was prepended to the subdirectory name and printed when nmake recursed into and from a subdirectory via the
:MAKE:operator. The current subdirectory is no longer printed by default making the variables more flexible. For example, the recurse messages can now be defined to print messages in the style of other build tools, which may allow integration with other tools that expect such output.
$(RECURSE_MESSAGE)in the definition of
recurse_end_message. For example:
recurse_begin_message = STARTING DIR $(RECURSE_MESSAGE)
JAVAPACKAGEROOTmust be defined to use the
JAVAPACKAGEROOTis undefined when building a makefile that uses
:JAVA:nmake will return an error indicating
JAVAPACKAGEROOTmust be defined. Prior releases of nmake did not use this variable.
:JAVA:assertion. This does not include projects who have defined their own
JAVAPACKAGEROOTas described in New Features: Java inside-package local build.
The following is a list of known problems:
<include/file.h>to include the system headers so
/usrmust be part of the standard include search directories. However, probe does not currently detect this and such includes may cause errors. Also, some users have experienced run-time problems with shared libraries when using
aCCdue to nmake calling
ldto make the shared library instead of
aCC. Use the following in your
probe_hintsfile to work-around these issues:
case $CC_CC in *aCC) CC_STDINCLUDE="$CC_STDINCLUDE /usr" CC_LD="$CC_CC" CC_MEMBERS="\`\$(NM) \$(NMFLAGS) \$(*:N=*\$(CC.ARCHIVE):O=1) | \ \$(SED) \$(NMEDIT) -e \"s/^/-Wl,-u/\"\`" ;; esac