Alcatel-Lucent nmake Product Builder

Release Notes -- Alcatel-Lucent nmake alu3.9

July 2007
[Table of Contents] [Previous Section] [Next Section]

5. Known Problems and Remarks

5.1 Known Problems

The following is a list of known problems:

1. 980009 - problem in link=*
   The problem about using linking (specified using the link variable) to install targets in any adjacent nodes in viewpathing still exists. You may still use linking to install, but only in alternate nodes -- installation using copying must alternate with installation using linking. The problem occurs with both symbolic and hard linking.
2. 030042 - :cc: generated header rebuild
   If a C file is built by using :cc: and this C file shares a generated header file with a C++ file specified in the same makefile, the generated header file may get regenerated during the build causing the source files to keep recompiling. This can be avoided by building the C++ files before the C files, or by generating the header file in a separate makefile at an earlier time during the build.
3. 990099 - metarules not searched when CC.REPOSITORY is set
   The metarules may not be searched under the following conditions: there is a user defined metarule for a non-compiled file, variable CC.REPOSITORY is defined and CC.DIALECT contains either PTRIMPLICIT or PTRMKDIR, and :: is used to trigger the metarule. Note that CC.REPOSITORY and CC.DIALECT are defined as such in the probe file for some C++ compilers. The work-around is to add .IMPLICIT to the :: assertion, or to not use the :: assertion (such as add the target to :ALL: instead.)
4. 020018 - adding shared lib building in same makefile won't re-link
   An executable target will not be re-linked when a shared library that is built in the same makefile is added as a prerequisite to the executable. The work-around is to set force_shared=1.
5. 020051 - first metarule is used by mistake
   When multiple metarules generate the same source file target, such as %.c, the first metarule defined matching an existing file will be triggered instead of the metarule matching the explicit file prerequisite.
6. 040043 - metarule $(>) expands non-matching prerequisites
   The $(>) and $(*) automatic variables used in meta rules to expand the prerequisite files may expand files that don't match the prerequisite pattern. In the following example the built in %.c->%.o rule expands the .xyz file which is included on the command line when compiling the .c.

   $ cat Makefile
   %.c : %.xyz
           cp $(>) $(<)
   
   abc.o :: abc.xyz
   
   $ nmake
   + cp abc.xyz abc.c
   + cc -O -I- -c abc.c abc.xyz
   

   Fix this by defining the %.c->%.o meta rule locally to filter out the unwanted files.

   cat Makefile
   %.c : %.xyz
           cp $(>) $(<)
   
   %.o : %.c (CC) (CCFLAGS)
           $(CC) $(CCFLAGS) -c $(>:N=*.c)
   
   abc.o :: abc.xyz
   
   $ nmake
   + cp abc.xyz abc.c
   + cc -O -I- -c abc.c
   

7. 030057 - Sun Compilers
   A couple projects have reported problems using Sun 8 and above compilers where -I flags pointing to the system include files cause compiler errors. One work-around is to strip these -I flags from the command line. For example:

   %.o : %.c (CC) (CCFLAGS)
           $(CC) $(CCFLAGS:N!=-I/opt/sc8.0a/SUNWspro*) -c $(>)
   

8. 060019 - .SHARED.o strips ../ files from link line
   Shared libraries cannot be created with .o files referenced with a path starting with ../.
9. 070010 - fails to bind large files
   nmake does not have large file support and cannot reference files over 2 GiB in size.

5.2 Remarks

1. :LINK: does not handle archive files that are generated by :: or :LIBRARY: assertion operators. Users should avoid use of :LINK: on archive files.
2. When the cpp -I-S flag is on, -D-M is disabled. Users should not use these two flags together.
3. Users should avoid including the same header file with both <...>-style and "..."-style #include statements in source files managed by a single makefile. nmake will assign .STD.INCLUDE and .LCL.INCLUDE attributes to the header file, and this can result in incorrect -I lists in the compiler command lines generated.

[Table of Contents] [Previous Section] [Next Section]