Alcatel-Lucent nmake Product Builder

Release Notes -- Alcatel-Lucent nmake lu3.8

July 2006
[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 link=* to install targets in any adjacent nodes in viewpathing still exists. You may still use link=* to install, but only in alternate nodes.
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 :: is used to trigger the metarule. Note that CC.REPOSITORY is defined automatically for some C++ compilers in the probe file. 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 will be triggered instead of the metarule matching the file prerequisite suffix.
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. 060017 - :JAR: problem using * pattern without file extension
   The :JAR: operator uses shell patterns to pick up files to include in the jar archive. However the rules currently assume the file names include a .suffix at the end and specifying dir/* to pick up all files does not work correctly. Instead use dir/*.*. To pick up files that do not include a dot specify the full filename.
9. 060019 - .SHARED.o strips ../ files from link line
   Shared libraries cannot be created with .o files referenced with a path starting with ../.
10. 060022 - keepgoing jar targs do not rebuild after failure
    Targets of the :JAR: operator are not rebuilt if they fail during a build using the -k keepgoing option.

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]