Nokia Networks Home

Nokia nmake Product Builder

Quick Links

Related Products

Release Notes -- Nokia nmake lu3.2

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

4. Known Problems and Remarks

4.1 Problems

The following is a list of known problems:

  1. cpp dumps core on input containing long concatenated text strings (as generated by Orbix). Current workaround is to use a version of cpp built with large input buffer sizes. Contact technical support at nmake@alcatel-lucent.com to obtain a large-buffer cpp.
  2. 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.
  3. The state information of .SOURCE.mk does not work correctly in viewpathing. For instance, VPATH is set as VPATH=A:B and the Makefile contains statements like
        .SOURCE.mk : incl
        include "global.mk"
    The B node is built by using the "global.mk" in the B node. Then, the A node is built by using the "global.mk" in the A node. If the "global.mk" in A is removed, nmake cannot detect that "global.mk" is changed when the A node is built again.
     
    To work around the problem, users may use the -I flag on the command line to point the directory where the "global.mk" is located.
        $ nmake -Iincl
    Or a better solution is to avoid using .SOURCE.mk in the makefile and instead use:
        include "./incl/global.mk"
  4. cpp complains when it processes a C++ header file from /usr/include that contains long comments (more than 2 blocks). The work-around, which is to shorten the comments, may require help from the system administrator. The other work-around is to make a symbolic link to /usr/include and reference the header through this link by adding it to .SOURCE.h.

4.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. 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 always gets regenerated during the build. Since :cc: uses a separate statefile, the information in this statefile is not in sync with the normal statefile. Users should avoid this practice and should generate the header file in a separate makefile at an earlier time during the build.
  4. Users should avoid including the same header file with both <...>-style and "..."-style #include statements in source files managed by a single makefile. .STD.INCLUDE and .LCL.INCLUDE attributes will be assigned 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:31:18 EDT