Nokia Networks Home

Nokia nmake Product Builder

Quick Links

Related Products

Release Notes -- Nokia nmake lu3.2

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

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

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

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