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.
- Certification for Solaris Studio 12 update 2
- Probe fixes for gcc
- Improved support for Solaris 10 ksh (see issue 34)
- Fixes in Java build support
- Additional messages for the --explain option
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 firstname.lastname@example.org.
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.
- 070000 - bad packageroot error building in java root subdir
- 070001 - bad packageroot error with vpathed java files
- 100000 - jdeps symlink infinite loop
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.
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.
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.
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
.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
.myPROBE is defined
.AFTER attribute so it is triggered after
.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
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.STDINCLUDE have a directory
appended to the end of their initial definitions.
The probe hints feature allows settings to be overridden when the probe
file is generated, the local definitions go in the probe file itself.
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.
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/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
PROBEPATH to a colon separated list of directories.
nmake will search
lib/probe/C/pp/ when necessary) under each node
PROBEPATH. Probe files will be generated in the first
node if none are found. After the probe files are generated they can be
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.
We are interested in any feedback you might have about nmake. Please send comments / suggestions to email@example.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 firstname.lastname@example.org. Thanks for your support!