Nokia nmake Product Builder
Customer Support Newsletter

http://www.bell-labs.com/project/nmake/newsletters/

Issue No. 37 - March 2011
Contacts
Articles
  1. nmake 13 Release Schedule
  2. Javadeps Update
  3. Tool Repository
  4. Overriding probe Settings
  5. Feedback and Suggestions

nmake 13 Release Schedule

The team is working towards the nmake 13 release targeted for 3Q2011. Here are some of the changes targeted for the new release in addition to the usual fixes and enhancements.

Looking for Beta Testers

The nmake 13 beta period is tentatively scheduled for 8-June-2011 through 15-July-2011. The beta test phase helps us maintain compatibility with existing makefiles and build environments by running the new release on real world projects. If you are interested in trying the beta or would like updates on the beta status please let us know at nmake@alcatel-lucent.com.

index

Javadeps Update

Javadeps release alu2.2.6 is scheduled to be available in conjunction with nmake 13. Javadeps is the Java scanner used by nmake to provide dependency based Java support. Release alu2.2.6 is not required for nmake 13 but upgrading is suggested. This minor update includes the following fixes.

index

Tool Repository

New tools have been added to the Tool Repository for generating graphical build reports viewable with any Javascript/SVG compliant web browser (such as Firefox 3.6). The actual HTML formatting is generated from template files for easy customization. The repository contains full descriptions of the tools and example reports. Also the new Report Summary page lists all the available reports and visualizations. The new reports are:

[durations bar graph]
target_durations
Display job times in a bar chart. This bar chart shows triggered build job durations in seconds. Each bar is clickable allowing drill down to job details as formatted in a web-based build report. Includes variant reports to show job durations organized by directory and to show makefile execution durations for each leaf makefile.

[sunburst graph]
sunburst
Display targets and job times in a sunburst chart. In a sunburst view, triggered targets or Makefiles appear as wedges distributed radially around wedges representing parent Makefiles. Interior wedges represent Makefiles and edge (or leaf) wedges represent triggered targets. Wedges are colored according to their parent Makefile, so that sibling makefiles/targets share the same color. Clickable leaf node links allowing drill-down to per-target log details. Clickable links on non-leaf nodes dynamically focus into selected sub-parts of the build. Includes icicle variation which uses rectangular coordinates instead of radial.

[radial tree graph]
radialtree
Display targets in a radialtree chart. Clickable node links allowing drill-down to per-target log details.

index

Overriding probe Settings

The probe tool included with nmake runs tests on the compiler tool chain to tune nmake to the specific environment. A "probe file" is created for the compiler and OS version that contains the tuning in the form of several nmake variables used by the base rules. In some circumstances you may want to override these settings. The probe files can be edited directly but the changes will not survive if the files are regenerated or when new probe files are generated. Here are a few better options to override the probe settings.

Project Makefiles

The probe variables can be redefined in the project makefiles such as a global makefile. However, they have to be set so they are defined after nmake reads the probe file otherwise the probe file definitions will clobber the local definitions. This is done by settings the variables in a rule that is triggered after .PROBEINIT which is the rule that reads the probe file. The following example shows how to do this with the .myPROBE rule.

.PROBEINIT : .myPROBE

.myPROBE : .MAKE .AFTER .VIRTUAL .FORCE .REPEAT
        CC.SHARED = -shared
        CC.STDLIB += /opt/pkgX/lib
        CC.STDINCLUDE += /opt/pkgX/include

In this example .myPROBE is made a prerequsite of .PROBEINIT. .myPROBE is defined with the .AFTER attribute so it is triggered after .PROBEINIT. The .MAKE attribute means the action block contains nmake statements so it isn't executed by the shell. .VIRTUAL tells nmake the target isn't generated. .FORCE forces the rule to trigger and .REPEAT makes sure it is always triggered in case .PROBEINIT is triggered more than once. The action block sets three probe variables. CC.SHARED is changed to the indicated value while both CC.STDLIB and CC.STDINCLUDE have a directory appended to the end of their initial definitions.

Probe Hints

The probe hints feature allows settings to be overridden when the probe file is generated, the local definitions go in the probe file itself. A probe_hints script is installed in the directory containing the probe files and the script is used by the probe tool automatically any time a probe is run. For details on using this feature see the probe hints article in issue 9.

Local Probe

The local probe feature lets you define the location of the probe files so they can be maintained by the project. The files can be stored with the project source code and picked up in the viewpath or an alternate list of directories can searched. When upgrading nmake it is suggested to generate new probe files to compare the local copies so any probe updates in the new release can be incorporated.

To use the viewpath set localprobe=vpath and nmake will search for probe files under $(VROOT)/lib/probe/C/make/ (and $(VROOT)/lib/probe/C/pp/ if pp probe files are needed for the current compiler). If no probe files exist in the viewpath they will be generated in the top node. Once they are generated you can edit and maintain your local copies.

To use a directory outside the viewpath set localprobe=1 and define PROBEPATH to a colon separated list of directories. nmake will search lib/probe/C/make/ (and lib/probe/C/pp/ when necessary) under each node in PROBEPATH. Probe files will be generated in the first node if none are found. After the probe files are generated they can be maintained locally.

Classic Method

Finally, if you do manually edit a probe file you can guard against it being overwritten automatically by keeping the file writable by the owner. By default the probe information files have write permission disabled. To handle cases where edits are needed the files will not be overwritten if owner write permission is enabled.

index

Feedback and Suggestions

We are interested in any feedback you might have about nmake. Please send comments / suggestions to nmake@alcatel-lucent.com.

We're also open to suggestions for future articles. If there is anything you would like to see in the newsletter please send us a note to nmake@alcatel-lucent.com. Thanks for your support!

index

<<home / newsletters