The team is working towards the nmake 14 release targeted for 3Q2012. The new release focuses on bug fixes and stability and includes over 25 fixes, including fixes for XML build logs, probe fixes for gcc and g++, fixes for several panic errors, improved error handling for large files, and more. The nmake 14 beta period is tentatively scheduled for 11-June-2012 through 16-July-2012 and includes beta of the new Javadeps alu2.3 release (see issue 39). The beta test phase is extremely important as it helps us maintain compatibility with existing makefiles and build environments by running the new release on real world projects. As such, the beta phase contributes directly to the stability of the product. All feedback from the beta is helpful so 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.
A new release of the nmake Eclipse CDT plugin is under development with release targeted for 4Q2012. The plugin will support the upcoming Eclipse Juno release expected June, 2012. Planned new features include an nmake error parser, auto-enablement of the nmake error parser in the nmake builder definitions, and revamped plugin documentation available in multiple formats. Productization improvements include moving to the Eclipse standard major.minor.service.qualifier plugin version numbering scheme for improved interoperability with the Eclipse p2 provisioning system, plugin signing for improved verification during plugin installation, and updated branding elements. Under the hood, the plugin release builds will move to a fully automated, "headless", build process against a controlled target platform, leading to higher quality and repeatable product. The plugin will continue to support the features of the existing experimental release 0.5.0 release, currently available at http://www.bell-labs.com/project/nmake/download/eclipse/.
New FAQ entries for the following topics have been added to the web site.
.AFTER special atoms can be used
to extend a rule by triggering another rule before or after the first rule.
Another option is to use a .FUNCTION rule. The following example runs a
local audit tool before compiling a source file.
.AUDIT rule returns shell statements that are expanded
$(.AUDIT) variable in the original shell action.
$ cat Makefile %.o : %.c (CC) (CCFLAGS) $(.AUDIT $(CCFLAGS)) $(CC) $(CCFLAGS) -c $(>) .AUDIT : .FUNCTION local flags flags := --strict $(%:N=-I*) return myaudit $(flags) $(>>) CC = gcc .SOURCE.h : inc1 inc2 :ALL: a :: a.c b :: b.c c :: c.c $ nmake + myaudit --strict -Iinc1 -I- a.c + gcc -O -Iinc1 -I- -c a.c + gcc -O -o a a.o + myaudit --strict -Iinc2 -I- b.c + gcc -O -Iinc2 -I- -c b.c + gcc -O -o b b.o + myaudit --strict -Iinc1 -Iinc2 -I- c.c + gcc -O -Iinc1 -Iinc2 -I- -c c.c + gcc -O -o c c.o
In some cases this approach has some advantages over
- Less overhead by running a single shell action instead of two separate shell actions.
- Data can be easily passed to the function as a parameter and referenced
- The function can be inserted anywhere in the shell action, at the beginning, end, or between other commands.
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!