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 firstname.lastname@example.org.
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
localjavadepsare now maintained in the state file and updated when out of sync
- MS Visual C++ compiler supported on Interix
- New environment variable
UMASKCHANGEto disable umask change
- :JAR: makefiles now works with
- Enhanced manifest file support for :JAR:
jarappendsetting 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
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 email@example.com.
Non-Lucent customers interested in an Enterprise Site License can also contact us at firstname.lastname@example.org.
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
.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):
VERSION_ENVIRONMENT is already being set you can use
a colon separated list:
When you run
nmake it will now generate a new probe file
for the value of
CC_VERSION and any other variables in
$ 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.