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

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:

Compatibility - It is a common practice to create a Makefile in every directory containing source when using nmake with C and C++, which controls the building of the source files in that directory. This feature allows Java developers to follow this common practice. However, there's some difference between the use of a Java local Makefile and that of a traditional C++/C local Makefile. A Java local Makefile will not be called recursively from higher level Makefiles to perform recursive builds, the local Makefile exists for the developer's convenience. Only the top level Java Makefile controls global builds.
Convenience - A local Makefile allows developers to follow the familiar edit/build sequence without leaving the working directory.
Performance - The local Makefile allows the developer to easily specify a set of directory-local Java files and bring the local targets up-to-date with the minimum amount of work. Non-package-local Java files are updated as required.

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 form $(VROOT)/<java-root-offset>.

See the :JAVA: man page for details and examples. The man page is named doc/jman.html in the nmake lu3.5 package.

2.2 :: operator support for building shared libraries

The :: 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 the :LIBRARY: operator.

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 "lib". 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

2.3 quoteinclude

The new quoteinclude feature allows the integration of tools that do not support -I- for referencing include files in the viewpath. By setting 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 $(quoteinclude). The severity level matches the level specified in the nmake error statement.

The quoteinclude feature is useful for projects using compilation tools whose native preprocessor does not support the -I- option, 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 use of #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 support -I-.

By default, $(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

2.4 IDL scan rule

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

The .SOURCE.idl atom is used to define search directories for .idl files, including include files. The -I 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.

2.5 Multiple language support for -I-

A framework is now in place to support the scanning of multiple languages requiring -I- support. This includes a new, generalized .INCLUDE. function which generates include file search flags.

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 -I flags for custom scan rules whose compile tools support -I-:

    xxFLAGS &= $$(.INCLUDE. <lang> -I -I-)

2.6 Prefixinclude for native preprocessors

The prefixinclude feature now has support for native preprocessors. When using a native preprocessor which supports -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 defined by .SOURCE.h. File hello.c includes "abc/hello.h" which includes "h2.h" (also under abc/.) Note, when the nmake supplied preprocessor is used, -Iinclude/abc is not needed and is not added to the command line.

    .SOURCE.h : include
    hello :: hello.c

    $ nmake
    + cc -O -Iinclude -Iinclude/abc -I- -c hello.c
    + cc -O -o hello hello.o

2.7 Global version stamp in all binary executables

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) $

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

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