http://www.bell-labs.com/project/nmake/newsletters/
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.
globaljavadeps and localjavadeps are now
maintained in the state file and updated when out of syncUMASKCHANGE to disable umask
changenmakelogjarappend setting to allow multiple :JAR: makefiles
to update the same target jar fileA new Javadeps lu2.2.2 release is also scheduled for the same time. Here are the fixes targeted for Javadeps lu2.2.2:
JAVAPACKAGEROOT too deepFor 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.
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.
<<home / newsletters