The team is working towards the nmake 15 release targeted for 3Q2013. In addition to the usual fixes and enhancements the changes targeted for the release include the following:
- New .DIRECTORY special atom for bound directories (similar to .REGULAR)
- Enhanced options for the :P=X edit operator to expand only existing regular files, directories or symbolic links
- New read -l option for the nmake read command to read a line at a time, useful for reading from pipes
- :MAKE: support for relative paths in the MAKEFILES variable
- New .TRIGGER.inode special atom to trigger an update based on inode comparison
- PWD handling for Eclipse sub-directory builds
- Updates for :LIBRARY:, clobber, probe, build logs, man pages and more
The nmake 15 beta period is tentatively scheduled for 11-June-2013 through 16-July-2013. 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.
The upcoming nmake 15 release is targeted to include new options to the :P=X edit operator. Currently :P=X returns each token that is a path name of an existing file of any type. The current behavior is not changing and remains the default. nmake 15 introduces new options to refine the output to specific types of files. The new synopsis looks like this:
The :P=XP form does a physical test on the tokens such that symbolic links are tested without following the link. Any combination of the new F, D, and L options may be specified to select regular files, directories, or symbolic links respectively. The following example demonstrates the new options.
$ ls -l total 8 -rw-r--r-- 1 richb richb 337 Apr 16 11:07 Makefile drwxr-xr-x 2 richb richb 4096 Apr 16 10:54 dir1 -rw-r--r-- 1 richb richb 0 Apr 16 10:53 file1 lrwxrwxrwx 1 richb richb 6 Apr 16 11:07 linkbroken -> broken lrwxrwxrwx 1 richb richb 4 Apr 16 10:54 linkdir -> dir1 lrwxrwxrwx 1 richb richb 5 Apr 16 10:54 linkfile -> file1 $ cat Makefile FILES = file1 dir1 linkfile linkdir linkbroken nofile targ: : FILES = $(FILES) : : FILES:P=X = $(FILES:P=X) : FILES:P=X=F = $(FILES:P=X=F) : FILES:P=X=D = $(FILES:P=X=D) : FILES:P=X=L = $(FILES:P=X=L) : FILES:P=X=FD = $(FILES:P=X=FD) : FILES:P=X=FDL = $(FILES:P=X=FDL) : : FILES:P=XP = $(FILES:P=XP) : FILES:P=XP=F = $(FILES:P=XP=F) : FILES:P=XP=D = $(FILES:P=XP=D) : FILES:P=XP=L = $(FILES:P=XP=L) : FILES:P=XP=FD = $(FILES:P=XP=FD) : FILES:P=XP=FDL = $(FILES:P=XP=FDL) $ nmake + : FILES = file1 dir1 linkfile linkdir linkbroken nofile + : + : FILES:P=X = file1 dir1 linkfile linkdir + : FILES:P=X=F = file1 linkfile + : FILES:P=X=D = dir1 linkdir + : FILES:P=X=L = + : FILES:P=X=FD = file1 dir1 linkfile linkdir + : FILES:P=X=FDL = file1 dir1 linkfile linkdir + : + : FILES:P=XP = file1 dir1 linkfile linkdir linkbroken + : FILES:P=XP=F = file1 + : FILES:P=XP=D = dir1 + : FILES:P=XP=L = linkfile linkdir linkbroken + : FILES:P=XP=FD = file1 dir1 + : FILES:P=XP=FDL = file1 dir1 linkfile linkdir linkbroken
Here are some key points from the example.
- The :P=X form expands symbolic links as their link destination so they expand with the F and D options.
- The :P=XP form tests symbolic links without following them so links are expanded with the L option.
- Broken symbolic links are expanded with the :P=XP form because the link itself exists.
Alcatel-Lucent nmake is frequently used in development projects based on remote hosts; in this common scenario development activities including edit, build, debug traditionally occur on the remote host.
Eclipse CDT provides a rich environment for C/C++ development and is a natural tool to consider for use in nmake based development, however, Eclipse CDT was developed for, and runs best on the local desktop. A number of approaches to remote development with Eclipse CDT have been proposed and implemented, with varying trade-offs in performance and functionality.
A relatively recent approach has been developed in the Eclipse Parallel Tools Platform (PTP) project, called "Synchronized Projects." Synchronized Projects provide a hybrid approach to remote development that provides many of the benefits of local development while working on a remote project. Even though targeted at development of parallel applications, PTP Synchronized Projects are useful for regular (non parallel) C/C++ projects where the project under development is remote.
As of Eclipse 4.2 (Juno release), PTP Synchronized Projects with Remote Tools appears to provide a workable option for Eclipse remote development with nmake. We have successfully set up a moderate sized C/C++ project using Eclipse 4.2 running on a local Centos 6.3 system working with a development project based on a remote RHEL 5.7 host. In the tested configuration, builds and launches occur on the remote Linux server, while Eclipse CDT indexing and source editing occur locally. Source synchronization is automatic (performed transparently using git) and is fast after the initial sync.
See the Parallel Tools Platform (PTP) User Guide for more information about PTP. Section Introduction to PTP Project Types provides a summary description of synchronized projects in comparison to traditional local projects and pure remote projects.
A handy nmake feature that is relatively unknown is the Makeargs file. If a file named Makeargs or makeargs exists in the current directory nmake will read it to obtain command line arguments, one argument per line. This can be useful for developers to locally set up custom arguments needed for their current work. It could also be used to temporarily set arguments for an automated build where adjusting the command line is difficult. The Makeargs file is not viewpathed and must be in the current local directory where nmake is run. Alternate filenames can be used by defining them in the MAKEARGS environment variable separated by colons.
Any command line arguments may be specified, including options, makefile targets, common actions, variable settings, etc. The same recursion rules apply as if the arguments were on the command line. The arguments from the file are placed in front of the actual command line arguments and may be overridden by the command line. Lines starting with # are taken as comments. Here is a simple example.
$ cat Makefile BINDIR = $(VROOT)/bin targ1 :: t1.c targ2 :: t2.c targ3 :: t3.c $ cat Makeargs --keepgoing install $ nmake + cc -O -I- -c t1.c + cc -O -o targ1 t1.o + cc -O -I- -c t2.c t2.c: In function `main': t2.c:3: error: syntax error before '}' token make: *** exit code 1 making t2.o + cc -O -I- -c t3.c + cc -O -o targ3 t3.o + cp targ1 ../bin/targ1 + cp targ3 ../bin/targ3 make: *** 1 action failed $ vi t2.c $ nmake + cc -O -I- -c t2.c + cc -O -o targ2 t2.o + cp targ2 ../bin/targ2 $ vi Makeargs $ cat Makeargs --keepgoing #install all CC=gcc CCFLAGS+=-g $ nmake + gcc -O -g -I- -D_TRACE_ -c t1.c + gcc -O -g -o targ1 t1.o + gcc -O -g -I- -D_TRACE_ -c t2.c + gcc -O -g -o targ2 t2.o + gcc -O -g -I- -D_TRACE_ -c t3.c + gcc -O -g -o targ3 t3.o
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!