Nokia nmake Product Builder
Customer Support Newsletter

Issue No. 26 - August 2007
  1. nmake alu3.9 Released
  2. Using Sun's -library=x compiler flags
  3. Large File Support

Alcatel-Lucent nmake alu3.9 Released

We are pleased to announce availability of Alcatel-Lucent nmake release alu3.9. nmake alu3.9 provides the following new features and significant enhancements:

nmake alu3.9 provides other bug fixes and enhancements as well. See the release notes for more information.

With few exceptions, nmake alu3.9 is upwardly compatible from nmake lu3.8. Current customers may upgrade to nmake alu3.9 using existing installed licenses, no license upgrade is required. See the alu3.9 release page for download information.


nmake alu3.9 is compatible with JavaDeps lu2.2.2 released July of 2006. There is no new JavaDeps release coninciding with alu3.9.


Using Sun Studio -library=lib compiler flags

The Sun Studio C++ compilers include the -library=lib flag to incorporate the specified library into compilation and linking. The flag may alter the compiler's header and/or library search paths. When including the flag in nmake's CCFLAGS variable the flag is passed to the compiler but nmake is not aware of the compiler's change in search behavior and cannot use the modified search paths for binding headers and libraries.

To make nmake aware of the new search paths nmake must probe the compiler with the flag to generate probe files for the specific configuration. The new probe files will define the proper search paths for nmake. To do this add the flag to the CC variable instead of CCFLAGS and nmake will automatically generate the necessary probe files if they don't already exist. For example:

CC = /opt/SUNWspro/bin/CC -library=iostream

Or if CC is set in a global makefile the flag can be added in a local makefile as follows:

CC += -library=iostream

After the probe file files are generated you can see the changes:

$ probe -l C make /opt/SUNWspro/bin/CC | grep ^CC.STDINCLUDE      
CC.STDINCLUDE = /opt/SUNWspro/prod/include/CC/Cstd /opt/SUNWspro/prod/include/CC
 /opt/SUNWspro/prod/include/CC/rw7 /opt/SUNWspro/prod/include/cc /usr/include /o
pt/SUNWspro/prod/include/CC/. /opt/SUNWspro/prod/include/CC/Cstd/. /opt/SUNWspro

$ probe -l C make "/opt/SUNWspro/bin/CC -library=iostream" | grep ^CC.STDINCLUDE
CC.STDINCLUDE = /opt/SUNWspro/prod/include/CCios /opt/SUNWspro/prod/include/CC/C
std /opt/SUNWspro/prod/include/CC /opt/SUNWspro/prod/include/CC/rw7 /opt/SUNWspr
o/prod/include/cc /usr/include

It is important for nmake to use the correct search paths to track the dependencies. This technique can be used for any compiler flags that similarly affect its configuration.


Large File Support

Large file support is under consideration as a new feature. But at this time nmake cannot reference files over 2 GB in size. If such a file is used as a prerequisite nmake will not see it and will report an error.

$ ls -l
total 4202560
-rw-r--r--   1 richb    richb         43 Aug  3 15:07 Makefile
-rw-r--r--   2 richb    richb    2147483648 Aug  3 14:46 bigfile

$ cat Makefile 
targ : bigfile
	echo $(*) > $(<)

$ nmake
make: don't know how to make targ : bigfile

Here is one possible work-around for this situation. In the following makefile the variable BIGFILE is set to the path of the first bigfile in the viewpath (we assume the native /bin/ls supports large files.) BIGFILE can be used in the action block instead of an automatic variable such as $(*). The variable BIGFILE.STAMP is set to the ls -l output of the file which includes the modification date. This variable is used as a state variable prerequisite to the target so if the date changes the rule is triggered.

$ ls -l
total 4202568
-rw-r--r--   1 richb    richb        224 Aug  3 15:41 Makefile
-rw-r--r--   2 richb    richb    2147483648 Aug  3 14:46 bigfile

$ cat Makefile 
        set +x
        for P in $(*.VIEW)
                /bin/ls ${P}/bigfile 2>/dev/null && break

        silent ignore /bin/ls -l $(BIGFILE)

        echo $(BIGFILE) > $(<)

$ nmake
+ echo ./bigfile
+ 1> targ

$ nmake

$ touch bigfile 

$ nmake
+ echo ./bigfile
+ 1> targ

Of course the ls -l output includes other data besides the date which could cause BIGFILE.STAMP to change and trigger the target to update. To limit the sensitivity the ls output can be piped to another command to strip out the unwanted data.

Here is an example of the same makefile with bigfile down the viewpath instead of the local node.

$ ls -l
total 8
-rw-r--r--   1 richb    richb        224 Aug  3 15:41 Makefile

$ nmake
+ echo /home/richb/n26/large/v2/bigfile
+ 1> targ

Another option could be to split the large file into smaller, manageable pieces and concatenate them back together in the shell action. For example:

$ ls -l
total 4202584
-rw-r--r--   1 richb    richb         71 Aug  3 16:17 Makefile
-rw-r--r--   1 richb    richb    1073741824 Aug  3 16:16 bigfile.01
-rw-r--r--   1 richb    richb    1073741824 Aug  3 16:21 bigfile.02

$ cat Makefile 
targ : bigfile.01 bigfile.02
        cat $(*:N=bigfile.*:H<=) | mytool > $(<)

$ nmake
+ mytool
+ cat bigfile.01 bigfile.02
+ 1> targ


<<home / newsletters