Nokia Networks Home

Nokia nmake Product Builder

Quick Links

Related Products

Release Notes -- Nokia 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]

Last Update: Friday,12-Aug-2016 12:33:34 EDT