Alcatel-Lucent nmake Product Builder
Customer Support Newsletter

lu3.8 Release Progress

The nmake team is working towards release lu3.8 targeted for 3Q2006. An official announcement will be made to the mailing list when the release is ready. We are also planning a beta period prior to the release. If you are interested in trying the beta please let us know at nmake@alcatel-lucent.com.

In addition to the usual fixes and enhancements here are some of the more significant changes in the release.

• Introduction of new platform support: Red Hat Enterprise Linux® 3, Solaris 10
• Improved support for Sun C++ 7.x and 8.x compilers
• :JAVA: performance enhancements
• Support for java builds from a node other than the source node
• Java builds filter out #empty files
• globaljavadeps and localjavadeps are now maintained in the state file and updated when out of sync
• MS Visual C++ compiler supported on Interix
• New environment variable UMASKCHANGE to disable umask change
• :JAR: makefiles now works with nmakelog
• Enhanced manifest file support for :JAR:
• New jarappend setting to allow multiple :JAR: makefiles to update the same target jar file

A new Javadeps lu2.2.2 release is also scheduled for the same time. Here are the fixes targeted for Javadeps lu2.2.2:

• Converting to relative path gives bad path
• Javadeps incremental scan gives incomplete dependencies
• Javadeps misses import pkg.class dependencies
• Certain vpath crashes jdeps
• Exception error when JAVAPACKAGEROOT too deep

Lucent Project Licenses

For internal Lucent projects please note that several Lucent business units are covered this year for nmake and Sablime licenses under an Enterprise Site License. Adding more hosts and/or users in these business units, even for new projects, will not incur any additional costs. The units covered are NSG, LWS (including NOS), IT and Bell Labs. The host machine must be Lucent owned and supported. If you have any questions or are unsure of your status please contact software@alcatel-lucent.com.

Non-Lucent customers interested in an Enterprise Site License can also contact us at software@alcatel-lucent.com.

Probe files for different compiler versions

Sometimes it is necessary to reprobe a C/C++ compiler when the compiler is upgraded in place. Some compilers use different standard include and library paths; for example with the compiler version in the path. Trying to use the old paths with the new compiler causes errors.

Here is a technique for keeping different probe files for different versions of the compiler so when the compiler is updated it will automatically be reprobed. We'll use the VERSION_ENVIRONMENT variable discussed in an earlier issue. First, set an environment variable containing the version of the compiler. This should be set automatically in your .profile or project setup scripts.

For example, the following command gives us a suitable version string for gcc:

$ gcc --version | grep ^gcc
gcc (GCC) 3.4.6

So we will include the following in our setup scripts:

export CC_VERSION=$(gcc --version | grep ^gcc)

In the same setup script add this variable name to VERSION_ENVIRONMENT (not the value just the name):

export VERSION_ENVIRONMENT=CC_VERSION

If VERSION_ENVIRONMENT is already being set you can use a colon separated list:

export VERSION_ENVIRONMENT=OS_VERSION:CC_VERSION

When you run nmake it will now generate a new probe file for the value of CC_VERSION and any other variables in VERSION_ENVIRONMENT.

$ cat Makefile
CC = gcc
hello :: hello.c

$ nmake
probing C language processor /opt/exp/gnu/bin/gcc for make information
+ gcc -O -I- -c hello.c
+ gcc -O -o hello hello.o

$ probe -l C make gcc
...
CC.CC_VERSION = gcc (GCC) 3.4.6
...

When CC_VERSION changes you will automatically get a new probe file for the updated compiler.