Release Notes -- Alcatel-Lucent nmake lu3.4

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

2. New Features Introduced in Release lu3.4

2.1 Introduction of dependency-based Java build support

Dependency-based Java build support is provided through the new :JAVA: operator and requires the external javadeps package available for download from the nmake web site:

http://www.bell-labs.com/projects/nmake/release/jdeps.html

The :JAVA: operator uses dependencies among .java and .class files to insure that build steps run in the proper order, and that only necessary build steps get run. These dependencies are automatically derived from Java source files using the javadeps package. Complex requirements of Java builds, such as dependency cycles and implicit targets, are correctly handled.

Since commonly used Java compilers have a high startup overhead, :JAVA: provides an optional feature (enabled by default) which reduces the number of Java compiler invocations by batching calls to the compiler. This approach can dramatically reduce build times.

The :JAVA: operator has the format:

    :JAVA: files-or-directories

Java files to be built are specified by the right hand side arguments. There must be at least one right hand side argument. Each right hand side argument specifies a pathname and may one of the following types:

file

Pathname of a .java source file. Shell pathname expansion patterns such as *.java work as expected. This is typically, but not necessarily, a relative pathname.

directory

Pathname of a directory. This is equivalent to specifying the relative pathnames of all .java files which exist in the tree rooted at the specified directory. Shell pathname expansion is not supported for directories.

Please see the man page at docs/jman.html, included with the nmake package, for full details and options for using the new :JAVA: operator.

2.2 Probe hints

The probe_hints file provides a convenient and flexible way to specify local installation overrides for selected probe variables. Using this approach, nmake administrators provide a probe_hints file that is separate from the automatically generated probe file. Probe consults the probe_hints file whenever it generates a probe file, and uses the information in this file to guide the probe. The probe_hints file is supported for nmake configuration information only, not for cpp information.

The probe_hints file is a user-provided shell script which overrides selected probe variables by setting shell variables to the preferred values. Use of a probe_hints file has a number of advantages over direct editing of the generated probe information file:

1. Since probe combines the information from the hints file with the automatically derived probe information, probe can continue to be responsible for most of the information in the probe file even if the user needs to override a couple of individual probe variables.
2. nmake installations and upgrades are easier and less error prone since the probe_hints file may simply be transferred to the new installation. There is no need to generate a probe file, obtain the hashed path value, change the permissions, and manually modify the generated file, for each version of each compiler.
3. Since the probe file is not manually edited, we eliminate a source of run-time errors.
4. Since the hints file is automatically consulted by all future probe invocations, we avoid the problem of user-triggered probe invocations inadvertently generating incorrect probe data.

Please see Appendix A of the nmake User's Guide for details on creating a probe_hints file.

2.3 Improved support for Sun WorkShop(TM) 6 C++ compiler

New cpp support for Sun's SUNWCCh standard include rewriting rule as described in Section 5.7.4 "Standard Header Implementation" of Sun's C++ User's guide. For example, this allows cpp to search for include file <string.SUNWCCh> on Solaris 8 when <string> is included. To facilitate this behavior a new cpp pragma, suffixsunwcch, has been introduced and is set automatically by the probe tool.

2.4 Support for C++ implicit includes

Some C++ compilers are able to search for "implicit include" files to find template definitions. Since nmake's automatic file dependency generation is based on explicit #include statements, implicitly included files may not be set up as dependent files. Modifying these files may not cause the appropriate recompilations.

now a warning message is emitted at run time if the compiler has an implicit include feature in effect and the compiler provides some way to disable the feature. The warning message is stored in the baserules variable implicit_template_definition_warning. The warning may be suppressed by setting the variable to null.

If implicit_include=1 then nmake will attempt to emulate commonly used C++ implicit template definition search rules and automatically set up the required implicit header file dependencies. However, complete emulation of compiler implicit search rules cannot be guaranteed. The only foolproof approach is suppression of the compiler implicit include feature and use of explicit #includes.

2.5 cc-% support for adding flags to CCFLAGS

The cc-% feature has been extended to include cca-% and cca+% to add flags to CCFLAGS instead of replacing the flags. For example:

    CCFLAGS = -i -s
    hello :: hello.c

    $ mkdir cca-g

    $ nmake cca-g
    cca-g:
    + cc -i -s -g -I- -D_TRACE_ -c ../hello.c
    + cc -i -s -g -o hello hello.o

    $ ls -l cca-g
    total 416
    -rw-r--r--   1 nmake    sablime     5180 May 25 14:44 Makefile.mo
    -rw-r--r--   1 nmake    sablime    13675 May 25 14:44 Makefile.ms
    -rwxr-xr-x   1 nmake    sablime   180224 May 25 14:45 hello
    -rw-r--r--   1 nmake    sablime     3716 May 25 14:45 hello.o

2.6 Scoped CCFLAGS for :: operator

CCFLAGS may be set in the prerequisite list of a :: operator. The setting will be valid for the corresponding target and not the entire Makefile. One or more flags may be specified with a single CCFLAGS definition. For example:

    :ALL:
    abc :: abc.c CCFLAGS+="-g -Xt"
    xyz :: xyz.c

    $ nmake
    + cc -O -g -Xt -I- -c abc.c
    + cc -O -g -Xt -o abc abc.o
    + cc -O -I- -c xyz.c
    + cc -O -o xyz xyz.o

2.7 New what_version_nmake command

A new command, what_version_nmake, has been added to the nmake package. Run what_version_nmake to see the version of the nmake release and latest patch applied. Use the -v (verbose) flag to get a full list of all patches applied plus the version strings from various nmake components. The new file <nmake_root>/lib/make/version contains the current version information.

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