Nokia

Nokia nmake Product Builder

 

Nokia nmake Product Builder
lu3.2 Release Notes

Table of Contents

Released: May 1999

1. Introduction
1.1 Supported Hardware
1.2 Changes Impacting 3.1 Makefiles

2. New Features Introduced in Release lu3.2
2.1 Output Serialization for Parallel Jobs
2.2 Atom Dependency Reporting Tool
2.3 Local Probe File Support
2.4 Support of Instrumentation Tools
2.5 New recurse_begin_message and recurse_end_message
2.6 New .ACTIONWRAP Special Atom

3. Bug Fixes and Enhancements
3.1 cpp
3.2 Common Actions
3.3 Operators
3.4 Meta-rules
3.5 Probe
3.6 Variables
3.7 Miscellaneous

4. Known Problems and Remarks
4.1 Known Problems
4.2 Remarks


1. Introduction

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

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

1.1 Supported Hardware

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

1.2 Changes Impacting 3.1 Makefiles

The changes in this release are backward compatible with 3.1 Makefiles. This refers to the entire 3.1 family including releases 3.1.1 and 3.1.2. Every effort was made to insure the code changes did not change the documented behavior of the nmake features. For makefiles that conform to nmake's documentation there will be no makefile updates necessary to migrate from a 3.1 based release to lu3.2.


2. New Features Introduced in Release lu3.2

2.1 Output Serialization for Parallel Jobs

During execution, shell action blocks triggered by nmake command send data to their standard output and standard error streams. This information appears as it is generated, allowing real time build process monitoring. However, as a performance enhancement feature, nmake can be configured to allow concurrent and distributed execution of shell action blocks (to the extent possible given rule dependencies). Consequently, when nmake is configured to run more than one shell action block concurrently, the standard output and standard error of concurrently executing action blocks may intermingle, causing build output logs to become very difficult or impossible to interpret. This happens because when you have several compiles or nmakes processes running at the same time the output from all the compiles gets mixed together, you cannot tell which output goes with which command line and worse, which errors go with which specific compiles. The output serialization feature will reconstruct the build output (on the fly) so it is human readable again.

This feature introduces three new commands to the nmake bin directory: nmakelog, logfilter, and taglines. Only nmakelog is callable directly by the user.

To use the serialization feature, call nmakelog(1) instead of nmake(1). For example:

    $ nmakelog -f mymakefile.mk mytarget

This causes the serialized output to be appended to $makelog (makelog by default). See nmakelog(1) manual page for additional information about how to use this feature.

2.2 Atom Dependency Reporting

nmake's usefulness as a build tool arises from its ability to manage the dependencies between the objects used in constructing software. One of its strengths is the capability to infer object relationships using higher level programming constructs, which greatly simplifies build process maintenance. In a makefile, the objects primarily correspond to atoms, and dependencies are mapped out via assertions, either explicit or implied. Since many dependencies are "discovered" during its normal execution, the full range of atom dependencies is not generally available by reviewing makefiles. The support for Atom Dependency Reporting will allow users to generate dependency information (which can be displayed via dag(3), dot(3), dt(3) or ASCII text) without having to build your software.

This feature introduces six commands to the nmake bin directory: mamdag, mamdep, mamdot, mamdt, mamexec, and mamstate.

2.3 Local Probe File Support

The purpose of this feature is to allow users to place both the probe information generation shells and the probe information files in locations other than the nmake installation root, and to relax the access restrictions normally associated with probe file creation/modification. For advanced users, this feature provides flexibility in setting up custom compilation environments, without requiring changes to nmake's installation hierarchy.

This feature is flagged by the new localprobe=<value> base rule variable. When localprobe=vpath, the probe hierarchy is assumed at a node relative to the current VPATH. An alternate non-null setting induces the usage of the PROBEPATH, a colon-delimited set of directories which can be independent from the VPATH.

2.4 Support of Instrumentation Tools

The Instrument Base Rule has been modified to add support for additional code instrumentation tools. The supported tools are purify, purecov, quantify, sentinel, insight/insure and codewizard. As in previous releases, the instrumentation tools are used by setting the instrument variable:

    $ nmake instrument=codewizard

2.5 New recurse_begin_message and recurse_end_message

Two new variables were added which allow the user to specify messages to be displayed when nmake recurses to, and returns from a sub-directory. The variable recurse_begin_message adds a message to be displayed in front of the default message (the directory name) when nmake enters a directory. The variable recurse_end_message adds a message to be displayed (there is no default) to be displayed when nmake returns from a directory.

Example 1) default behavior is same as previous nmake releases:

    :MAKE: a b c

    $ nmake
    a:
    + : /build/a
    b:
    + : /build/b
    c:
    + : /build/c

Example 2) set recurse_begin_message and recurse_end_message for custom messages:

    recurse_begin_message = "Enter dir"
    recurse_end_message = "Exit dir"
    :MAKE: a b c

    $ nmake
    Enter dir a:
    + : /build/a
    Exit dir a
    Enter dir b:
    + : /build/b
    Exit dir b
    Enter dir c:
    + : /build/c
    Exit dir c

2.6 New .ACTIONWRAP Special Atom

The .ACTIONWRAP special atom allows the user to define a rule action which is expanded in place of each shell action prior to command execution. The expansion takes place in the original rule context so that automatic variables refer to the original rule values. In particular, $(@) expands to the action for the original rule. This allows easy dynamic modification of all rules in an nmake execution.

For example, the following Makefile modifies all shell action rules such that, when modify_rules=1, a message containing the current date and time is printed before and after each compilation and linker command step:

    if modify_rules
    .ACTIONWRAP :
	    : "starting $(<:A=.COMMAND:?command ??)target $(<) at `silent date`"
	    $(@)
	    : "target $(<) completed at `silent date`"
    end

    a :: a.c

3. Bug Fixes and Enhancements

3.1 cpp

  1. Fixed a problem where cpp was dumping core when compiled with HP cc compiler. The problem was due to an HP C optimizer bug.
  2. Fixed cpp to warn when a macro is called with more arguments than specified in its definition.
  3. Fixed a problem where cpp dumped core in ANSI mode on unclosed macro invocation in a certain context.

3.2 Common Actions

  1. Fix in .DO.INSTALL where link=1. This fix allows the install common action to work properly with symbolic links.
  2. Fixed a bug where the clobber common action would not remove targets whose name matched $(VROOT)/*.
  3. Enhanced clobber common action so that .ti files are removed when used with Lucent C++ 5.0. This enhancement is all that is needed to allow use of nmake with C++ 5.0 to build applications.
  4. The cc- common action now supports +opt and multiple options. This common action assumes the existence of one or more cc-opt subdirectories, where opt is any valid CCFLAGS value (ex. g, p, pg, etc.). When nmake is invoked with the cc- or cc-opt common action, it will build the executables for each of these compiler options or the specific one specified by opt and place them in the corresponding directory.
     
    The enhancement allows the use of +opt compiler options and also allows multiple options to be specified using a tilde (~) to separate each option.
     
    Examples:
        $ nmake cc+eh
        cc+eh:
        + ppcc -i /home/bugati/nmake/build/lu3.2/karna-bld1/lib/cpp cc+eh
        -I-D/home/bugati/nmake/build/lu3.2/karna-bld1/lib/probe/C/pp/BFE0A
        4FEobincc -I- -c ../a.c
    
        $ nmake cc-g~+eh~-xtime
        cc-g~+eh~-xtime:
        + ppcc -i /home/bugati/nmake/build/lu3.2/karna-bld1/lib/cpp cc -g
        +eh -xtime -I-D/home/bugati/nmake/build/lu3.2/karna-bld1/lib/prob
        e/C/pp/BFE0A4FEobincc -I- -D_TRACE_ -c ../a.c

3.3 Operators

  1. A fix for :LIBRARY: support for required libraries. When building a library using :LIBRARY: and specifying -lname library prerequisites (or listing required library names on the lhs) nmake will keep track of the required libraries. When the target library is used to link with an executable the required libraries will be automatically included in the link. In some cases a valid required library was ignored and not included when linking with the target library. Now these required libraries are included when linking with the target library.
  2. :LIBRARY: now does a validation check on its target to help insure proper usage.
  3. :LINK: now supports the following usage:
        lhs :LINK: rhs
    Where rhs may be a file name or a variable expansion evaluating to a file name. rhs is evaluated separately for each element of lhs. During each expansion $$(<) evaluates to the current target.
     
    For example:
        LINKS = link1.suf1 link1.suf2 link2.suf1 link2.suf2
    
        :ALL: $(LINKS)
    
        $(LINKS) :LINK: $$(<:B=orig:S)
    
        $ nmake
        + ln orig.suf1 link1.suf1
        + ln orig.suf2 link1.suf2
        + ln orig.suf1 link2.suf1
        + ln orig.suf2 link2.suf2
  4. :MAKE: now allows targets specified on the lhs to be recursively built. For example, the following makefile will build the targ1 target in directories a, b, and c. Directories d, e, and f will not be visited.
        targ1 :MAKE: a b c
        targ2 :MAKE: d e f
    
        $ nmake recurse targ1
  5. :MAKE: bug fixes. When specifying dir/file.mk as a prerequisite to :MAKE: nmake would build file.mk in the current directory without changing directory to dir. Also dir/file.mk was only found in the current viewpath node, it was not found if it only existed down the viewpath.

3.4 Meta-rules

  1. Added support for .cpp and .cxx files in the base rules. User defined meta-rules are no longer needed to build source files which use .cpp or .cxx suffixes.

3.5 Probe

  1. Probe update for new SGI C compiler. The new SGI C compiler understands -KPIC but not -Kpic. The probe script now checks for both options explicitly instead of only -Kpic.
  2. Probe no longer hangs when probing cross compilers.
  3. Fixed a bug which caused problems in the correct setting of CC.SUFFIX.SHARED when probing with a -L option stored in the $(CC) variable.
  4. hppa has been included in the :machine: list of pp.def, for use in the preprocessor probe.

3.6 Variables

  1. Fixed a bug causing $(@) to erroneously expand to the null string when NPROC > 1.
  2. Improved treatment of state variable consistency. When using state variables defined at multiple levels in the viewpath, unnecessary rebuilds due to state variable consistency, induced by initial state variables found at a higher level of the viewpath affecting state variables found at a lower level of the viewpath, is no longer a problem.
  3. Updated variable PROTOCOPYRIGHT for Lucent Technologies.

3.7 Miscellaneous

  1. Better handling of $(PPCC) call in Makerules.mk when = options are in $(CC). This fix addresses problems encountered in using compiler options containing an "=" sign in conjunction with $(PPCC).
  2. The read -i <file> construct, introduced in Release 3.1, has been enhanced to read the entire input file, not just the first line from that file.
  3. Fixes for genlocal and hostinfo. genlocal would produce an error if hostinfo didn't return the expected output from a remote machine (for example if a compiler was not licensed). genlocal also failed to report some machines in the network. genlocal now uses niscat in addition to ypcat and /etc/hosts to get a list of possible machines in the network.
  4. Increased -I- support for native preprocessors. Now the native preprocessor is default if it supports -I-. With some compiler (ie. gcc) nmake would still use the cpp even though the native tools supported -I-. Defaulting to the native preprocessor can be overridden by specifying nativepp=0 to force the use of nmake cpp.
     
    prefixinclude is turned off when using the native preprocessor. When using compilers that support -I-, such as Lucent's C++ 4.0, sometimes header files would not be found due to the use of prefixinclude. Now prefixinclude is turned off when using any native preprocessor.
  5. Fixed problem in interaction between Lucent C++ 5.0 and iffe. The problem results from the different treatment of functions when extern "C" declarations are used.
  6. The print construct and :F edit operator now accept %[eEfFgG] conversion. For both the print construct and the :F edit operator, the %e, %E, %f, %F, %g, and %G conversion specifiers are now available.
     
    For example, an action block containing:
        print -f "%010.3f" 44.75
        print $("23.349":F=%.06e)
    yields:
        000044.750
        2.334900e+01
  7. Fix for core dump when using the -d1 option. In some scenarios of unbinding an atom, the debug option could lead to a core dump during debug output.
  8. A bug fix for 3.1.2 -I include file handling, when dealing with relative paths to include files in certain scenarios, has been addressed (full explanation below).
     
    Canonical case:
    A source file includes some X.h from .SOURCE.h (in different directory). A second source file includes some Y.h using a relative path to the location of Y.h. Y.h again includes X.h with no path specification. Then, the next source file which includes X.h gets the "cannot find include file" error.
     
    Test case is as follows:
        /* Makefile */
    
        .SOURCE.h : ../hdr
    
        main :: main.o first.o second.o third.o
    
        /* first.c */
    
        #include "X.h"
         
        first() 
        { 
    	    return(0);
        }
    
        /* second.c */
    
        #include "../hdr/Y.h"
         
        second()
        {
    	    return(0);
        }
    
        /* third.c */
    
        #include "X.h"
         
        third()
        {
    	    return(0);
        }
  9. Updated nmake User's Guide and nmake Reference Manual.
  10. Several updates to the man pages.

4. Known Problems and Remarks

4.1 Problems

The following is a list of known problems:

  1. cpp dumps core on input containing long concatenated text strings (as generated by Orbix). Current workaround is to use a version of cpp built with large input buffer sizes. Contact technical support at nmake@alcatel-lucent.com to obtain a large-buffer cpp.
  2. 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.
  3. The state information of .SOURCE.mk does not work correctly in viewpathing. For instance, VPATH is set as VPATH=A:B and the Makefile contains statements like
        .SOURCE.mk : incl
        include "global.mk"
    The B node is built by using the "global.mk" in the B node. Then, the A node is built by using the "global.mk" in the A node. If the "global.mk" in A is removed, nmake cannot detect that "global.mk" is changed when the A node is built again.
     
    To work around the problem, users may use the -I flag on the command line to point the directory where the "global.mk" is located.
        $ nmake -Iincl
    Or a better solution is to avoid using .SOURCE.mk in the makefile and instead use:
        include "./incl/global.mk"
  4. cpp complains when it processes a C++ header file from /usr/include that contains long comments (more than 2 blocks). The work-around, which is to shorten the comments, may require help from the system administrator. The other work-around is to make a symbolic link to /usr/include and reference the header through this link by adding it to .SOURCE.h.

4.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. 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 always gets regenerated during the build. Since :cc: uses a separate statefile, the information in this statefile is not in sync with the normal statefile. Users should avoid this practice and should generate the header file in a separate makefile at an earlier time during the build.
  4. Users should avoid including the same header file with both <...>-style and "..."-style #include statements in source files managed by a single makefile. .STD.INCLUDE and .LCL.INCLUDE attributes will be assigned 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:05 EDT