Nokia nmake Product Builder
Release Notes -- Nokia nmake lu3.2
[Table of Contents]
The following is a list of known problems:
- 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
firstname.lastname@example.org to obtain
a large-buffer cpp.
- 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.
- 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
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:
- 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.
- :LINK: does not handle archive files that are generated by
:: or :LIBRARY: assertion operators.
Users should avoid use of :LINK: on archive files.
- When the cpp -I-S flag is on, -D-M is disabled.
Users should not use these two flags together.
- 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.
- 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]
Last Update: Friday,12-Aug-2016 12:31:18 EDT