Nokia

Nokia nmake Product Builder

 

Nokia nmake Product Builder
lu3.4 Release Notes

Table of Contents

Released: June 2001

1. Introduction
1.1 Supported Hardware

2. New Features Introduced in Release lu3.3
2.1 Introduction of dependency-based Java build support
2.2 Probe hints
2.3 Improved support for Sun WorkShop(TM) 6 C++ compiler
2.4 Support for C++ implicit includes
2.5 cc-% support for adding flags to CCFLAGS
2.6 Scoped CCFLAGS for :: operator
2.7 New what_version_nmake command

3. Bug Fixes and Enhancements
3.1 Baserules
3.2 cpp
3.3 Engine
3.4 Operators
3.5 Probe
3.6 Variables
3.7 Miscellaneous

4. Changes Impacting lu3.3 Makefiles

5. Known Problems and Remarks
5.1 Known Problems
5.2 Remarks


1. Introduction

This document announces the new release of nmake version lu3.4. The version string lu3.4 distinguishes this as a product release from Lucent Technologies (lu) as opposed to AT&T's research versions. nmake is fully supported and is in wide production use throughout Lucent Technologies, AT&T, and elsewhere. nmake lu3.4 is in no way connected to any version of nmake from AT&T research.

These lu3.4 Release Notes discuss in detail the new features, highlights bug fixes, additional enhancements, and known problems.

1.1 Supported Hardware

The lu3.4 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 at 908-582-5880, or send email to nmake@alcatel-lucent.com.


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


3. Bug Fixes and Enhancements

3.1 Baserules

  1. 990057 - possible problem with C++ implicit dependencies
    nmake is unable to track implicitly included files so issues a warning message (from variable implicit_template_definition_warning) if the compiler has an implicit include feature enabled and provides a means to disable it. Probing for make information detects compiler options to enable and disable an implicit include feature. These options are stored in the variables CC.IMPLICIT.INCLUDE.ENABLE and CC.IMPLICIT.INCLUDE.DISABLE respectively.
    See New Features: Support for C++ implicit includes
  2. 990096 - cc- does not support adding to existing CCFLAGS
    See New Features: cc-% support for adding flags to CCFLAGS
  3. 990140 - The implicit C++ templates problem
    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.
    See New Features: Support for C++ implicit includes

3.2 cpp

  1. 010008 - cpp support of Sun C++ system include rewriting rule
    cpp supports the rewriting rule for Sun C++ include files via the new suffixsunwcch pragma. Probing for cpp information detects the need for the new pragma.
    See New Features: Improved support for Sun WorkShop(TM) 6 C++ compiler

3.3 Engine

  1. 010007 - EXTRASTATE causing :cc: files to rebuild
    Under certain conditions source files specified with :cc: would be recompiled unnecessarily. This has been fixed.
  2. 990038 - error when bld archive before shared version in vpath
    Archive members were not being bound correctly. This caused problems finding .o files down the viewpath in certain situations, particularly where the same .o file was used to make two targets, the first target being an archive library. The binding of archive members has been fixed.
  3. 990100 - prereq change did not trigger rebuild
    A bug has been fixed where changes to a prerequisite list did not cause the corresponding target be remade. For example, if prerequisite library -lfoo was changed to -lbar then relink the target. But changing -lbar back to -lfoo would not cause another relink as expected.

3.4 Operators

  1. 980000 - new :JAVA: operator
    New :JAVA: operator to build java code. Refer to docs/jman.html for details on using :JAVA:.
    See New Features: Introduction of dependency-based Java build support
  2. 990073 - :MAKE: should support absolute path
    Recurse to a full path specified on the right of :MAKE: if the VPATH is unset. If the VPATH set then only recurse to a full path if it is inside the top viewpath node; if the full path is outside the top node then issue a warning message and do not recurse into the directory.
  3. 990097 - :LIBRARY: forgets -L args with sparcworks C++
    When using :LIBRARY: to make a shared library with the Sun Sparcworks C++ compiler, -L<dir> flags are omitted from the link line for any specified prerequisite libraries. This would cause link errors when making a shared library with prerequisite libraries and has been fixed.
  4. 990101 - set CCFLAGS for specific targets on lhs of ::
    You may now define more than one flag in CCFLAGS in the prerequisite list of a :: assertion. The flags will be used for building the corresponding target only.
    See New Features: Scoped CCFLAGS for :: operator
  5. 990121 - additional CC flag gets added each nmake run
    Using :cc: to identify C code and specifying a compiler flag on the corresponding :: assertion would keep adding the specified flag each time nmake was run. That is, the flag would be repeated multiple times on the compile line for each nmake execution. This also caused the file to keep rebuilding as it looked like the flags were changing. This behavior has been corrected.

3.5 Probe

  1. 010008 - cpp support of Sun C++ system include rewriting rule
    See cpp: 010008
  2. 990057 - possible problem with C++ implicit dependencies
    See Baserules: 990057
  3. 990114 - probe hints file
    The new probe_hints file provides a convenient way to specify local installation overrides for selected probe variables. The probe_hints file is consulted during the probe operation so further maintenance of probe files is unnecessary.
    See New Features: Probe hints

3.6 Variables

  1. New base rules variable implicit_template_definition_warning - see 990057
  2. New probe variable CC.IMPLICIT.INCLUDE.ENABLE - see 990057
  3. New probe variable CC.IMPLICIT.INCLUDE.DISABLE - see 990057
  4. New base rules variable implicit_include - see 990140

3.7 Miscellaneous

  1. 990115 - coshell remote shell fails if .profile does not exist
    When using coshell, if the user had no .profile in their home directory on the remote machine then the remote shell would fail. This has been fixed so coshell checks for the existence of the .profile before trying to source it.
  2. 990160- Uniform version identification
    The command what_version_nmake has been added to the nmake bin/ directory. This command returns the current version of nmake. The -v (verbose) flag shows the version of various nmake components.
    See New Features: New what_version_nmake command

4. Changes Impacting lu3.3 Makefiles

The changes in this release are largely backward compatible with lu3.3. Every effort was made to insure code changes did not change the documented behavior of nmake features. For makefiles that conform to nmake's documentation there will be no makefile updates necessary to migrate from a lu3.3 based release to lu3.4.


5. Known Problems and Remarks

5.1 Problems

The following is a list of known problems:

  1. The problem about using link=* to install targets in any adjacent nodes in viewpathing still exists. You may still use link=* to install, but only in alternate nodes.
  2. If a C file is built by using :cc: and this C file shares a generated header file with a C++ file specified in the same makefile, the generated header file may get regenerated during the build causing the source files to keep recompiling. This can be avoided by building the C++ files before the C files, or by generating the header file in a separate makefile at an earlier time during the build.

5.2 Remarks

  1. :LINK: does not handle archive files that are generated by :: or :LIBRARY: assertion operators. Users should avoid use of :LINK: on archive files.
  2. When the cpp -I-S flag is on, -D-M is disabled. Users should not use these two flags together.
  3. Users should avoid including the same header file with both <...>-style and "..."-style #include statements in source files managed by a single makefile. nmake will assign .STD.INCLUDE and .LCL.INCLUDE attributes to the header file, and this can result in incorrect -I lists in the compiler command lines generated.

Last Update: Friday,12-Aug-2016 12:31:41 EDT