Alcatel-Lucent nmake Product Builder

Release Notes -- Alcatel-Lucent nmake 3.0

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

5. Known Bugs and Remarks

5.1 Known Bugs

The following is a list of known bugs:

• When giving a value to a functional variable on the command line, the returning value may not be correct. To work around the problem, use the reread option. For example:

      nmake -o reread FUN=zz
      

  where FUN is the functional variable.
• Using link=* to install targets in any adjacent nodes under viewpathing may result incorrect installation. To work around this problem, one can use link=* to install in alternate views. For example, if VPATH is set to:

      VPATH=/n1:/n2:/n3
      

  you can use the default actions to install the targets in /n3 (the default action for installation is to copy the targets into install area), and specify link=* in /n2 to install the targets, then again use the default action to install in /n1.
• Panic on some file name aliasing cases, such as:

      all : lib.a $(PWD)/b.o
      lib.a :: a.c
      b.o:
      

  To work around the problem, one can remove the $(PWD).
• The special atom .ACCEPT used as an immediate rule affects only the first nmake invocation. The work around is to use it as a dynamic attribute.
• The coshell executable does not run on the Pyramid machine running OSx5.1, the IBM machine running AIX3.2, and the DEC machine running OSF1.2 and OSF1.3.
• cpp cannot handle the definition of #macdef block containing more than one #if, #ifdef, #ifndef, or #elif. This will cause core dumping.

      #macdef ARGPRINT(arg1, arg2, arg3)
      #if arg3 == 1
  	    printf("arg is 3\n");
      #endif
      #if arg2 == 2
  	    printf("arg is 2\n");
      #endif
      #if arg1 == 3
  	    printf("arg is 1\n");
      #endif
      #endmac
      

  The user has to find a different way to write the macro to avoid the core dump.
• Cannot handle file name >= 15 characters when building archive targets on those machines that ar(1) will truncate the file names to 14 characters (e.g., HPs). Recompile those file at every nmake invocation, since the truncated file names do not match the actual names. The work around for the problem is to change the file name to be <= 14 characters if it is possible.
• If INSTALLROOT is not set in the makefile or on the command line, the output from -M command line option gives incorrect value for INSTALLROOT. If INSTALLROOT is set and exported in the environment, the output from -M command line option still gives incorrect output for this variable. If the value of INSTALLROOT is set, but the value does not start with "..", the output from -M always gives $HOME as the value of this variable. The work around is to use -k in conjunction with -M and set value to INSTALLROOT either on the command line, or in the makefile, or in the environment.
• On Star Server FT B20 machine, probe does not generate correct value for CC.PIC when probing for /bin/cc. Manual modification is needed. The correct value should be -D_PIC.
• The coshell environment variable HOMEHOST used in action block of assertions does not get any value.
• The information in <nmake_install_root>/lib/cs/local may not be generated correctly. For example, type may contain machine name instead of machine type. Manual modification is needed.
• The :LINK: does not handle archive files, so user should avoid to use :LINK: on archive files.

5.2 Remarks

The followings are some remarks:

• Do not use ksh exit statement nmake actions; use the ksh false statement instead.
• To include a compiled makefile (e.g., include "global.mo") is invalid; use

      include "global.mk"
      

  instead.
• Shell patterns containing /* may be interpreted as comments; usr [/]* instead.

      case $i in
      "/"*)
  	    ...
  	    ;;
      esac
      

• If one uses a single makefile to build a shared library and an executable target whose prerequisite is the shared library built in the same makefile is also a prerequisite of the executable target, nmake won't link the .so version to the target, but will link the .a version instead. One can build the shared library and the target in separate makefiles, then the shared library will be linked to the target.
• :LIBRARY: does not build a debug version of shared library (e.g. libx-g.so).
• If library members (*.o files) are built by :cc:, the *.o files won't be removed.
• When *.o files are in the prerequisite list of an archive target, nmake will delete the prerequisites after the archive target is built. One can use arclean base rule variable to specify the *.o files to be removed.
• Label targets of :MAKE: do not work recursively.
• If there is a backslash and a new-line character (i.e. "\\n") inside C++ // comments, cpp treats the second line of it as a part of the comment. This conforms to the POSIX standard.
• To generate targets from .sh files, the user can also specify that target names be generated from a *.sh file, such as:

      a :: b.sh
      

  To make it work, one should specify the following specific action to the :: operator:

      a :: b.sh
  	    $(@%.sh>%)
      

• The special atom .ACCEPT does not apply to metarule targets. User has to put shell wrapper in the action of the meterules to accommodate it.
• If a compiler does not provide a flag or an environment variable for altering cpp, probe won't generate values for the variables CC.ALTPP.FLAGS and CC.ALTPP.ENV in the probe information file. In this case, the shell wrapper, ccc will take part in the compilation processing (ccc can be found in <nmake_install_root>/bin). ccc copies file into /tmp and uses cpp to preprocess the file, then lets the compiler do the rest of the compilation. This causes a debugging problem when compiling with the symbolic debugging flag on, because the source file location will be recorded as it is in /tmp. The work around is to set nativepp=1 on the command line when viewpathing is not used.
• If there are different versions of nmake under$INSTALLROOT and/or $HOME from the version you are using, nmake may pick up a wrong version of the base rules.
• When probe generates the configuration file for a language processor, it takes the value of __UNIVERSE__ as an attributes to hash for the configuration file name. If users working on the same project set the value of __UNIVERSE__ differently, they probably would use a different probe configuration files to build the software. To make sure that each of project member uses the same configuration file to build the software, each of them should set __UNIVERSE__ to be either att or ucb and export the environment variable, or use the ksh93 builtin universe.
• The error message similar to "/dev/fd/number: cannot open" may appear when executing nmake, this is because an old version of ksh is used. One should set and export COSHELL_OPTIONS=nodevfd in the environment before executing nmake.
• There is <nmake_install_roo>/lib/acpp included in the nmake 3.0 package. It is for some compilers (e.g., Sun's C++ compiler) which use acpp as its preprocessor.

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