Nokia

Nokia nmake Product Builder

 

Nokia nmake Product Builder
lu3.5 Release Notes

Table of Contents

Released: June 2002

1. Introduction
1.1 Supported Hardware
1.2 Customer Support

2. New Features Introduced in Release lu3.5
2.1 Java inside-package local build
2.2 :: operator support for building shared libraries
2.3 quoteinclude
2.4 IDL scan rule
2.5 Multiple language support for -I-
2.6 Prefixinclude for native preprocessors
2.7 Global version stamp in all binary executables

3. Bug Fixes and Enhancements
3.1 Baserules
3.2 cpp
3.3 Engine
3.4 Operators
3.5 Probe
3.6 Variables
3.7 Miscellaneous

4. Changes Impacting lu3.4 Makefiles

5. Known Problems and Remarks
5.1 Known Problems
5.2 Remarks


1. Introduction

This document announces the new release of nmake version lu3.5. nmake is fully supported and is in wide production use throughout Lucent Technologies, AT&T, and elsewhere.

These lu3.5 Release Notes discuss in detail the new features, highlights bug fixes, additional enhancements, and known problems.

1.1 Supported Hardware

The lu3.5 release has been ported to many UNIX-based systems. For a current list see the Availability Chart and the Download Page on the nmake web site, http://www.bell-labs.com/projects/nmake/. Or contact the Customer Support helpdesk below.

1.2 Customer Support

We provide patch support, where code changes are required, for nmake releases lu3.5 and lu3.4 (the latest two releases.) Customers using older releases can still acquire help in using the product, but genuine problems found in older releases will not be fixed. Such problems may require an upgrade to a current release or, when possible, a makefile work-around will be provided.

Fee-based services are also available. These include makefile rewrites, conversion of non-nmake makefiles to nmake, integration with vendor tools, build assessments, and porting nmake to new machines.

Contact Customer Support for any questions regarding nmake.


2. New Features Introduced in Release lu3.5

2.1 Java inside-package local build

The inside-package build feature allows developers to launch builds from within a Java package, rather than only the package root. There are several motivations for this feature:

The introduction of the Java inside-package build feature changes the :JAVA: operator so the variable JAVAPACKAGEROOT is mandatory and must be defined. JAVAPACKAGEROOT is normally the root directory of the Java source tree and contains the top level Makefile for building the entire Java tree. It is typically specified in the global makefile in the form $(VROOT)/<java-root-offset>.

See the :JAVA: man page for details and examples. The man page is named doc/jman.html in the nmake lu3.5 package.

See also Changes impacting lu3.4 Makefiles: Java inside-package local build.

2.2 :: operator support for building shared libraries

The :: operator now supports shared library targets. At this time the use of $(CC.SUFFIX.SHARED) in the target name is not supported. For portable makefiles across platforms, where shared libraries may have different suffixes, continue using the :LIBRARY: operator.

Warnings are emitted if a shared library is built without the necessary PIC flag (defined by variable CC.PIC), or if a shared library target name does not begin with "lib". Both of these cases may lead to problems linking with the library or cause an inefficient library, depending on the platform.

    CCFLAGS += $$(CC.PIC)
    libabc.so :: abc.c

    $ nmake
    + cc -O -KPIC -I- -c abc.c
    + ld -G -o libabc.so abc.o

2.3 quoteinclude

The new quoteinclude feature allows the integration of tools that do not support -I- for referencing include files in the viewpath. By setting quoteinclude=[1|2|3], nmake will emit a warning or error when a #include "..." directive is detected inside the viewpath and the viewpath contains more than one node. The error is issued with a severity level of the value of $(quoteinclude). The severity level matches the level specified in the nmake error statement.

The quoteinclude feature is useful for projects using compilation tools whose native preprocessor does not support the -I- option, and that for some reason cannot preprocess using the nmake supplied preprocessor (such as versions of Iona's IDL compiler prior to Orbix 2000.) Using quoteinclude, a project can effectively enforce the exclusive use of #include <...> directives, which do not require -I- for viewpath support. This allows projects to make full use of viewpathing, while using compilation tool chains which do not support -I-.

By default, $(quoteinclude) is null and no errors are issued.

    $ nmake quoteinclude=1
    make: warning: hello.c uses quoted include for hello.h
    + cc -O -KPIC -I. -I- -c hello.c
    + cc -O -KPIC -o hello hello.o

2.4 IDL scan rule

A scan rule for IDL code, called .SCAN.idl, is now defined in the base rules. IDL files are scanned for file prerequisites and candidate state variable references. Files ending with suffix .idl will be scanned automatically. IDL files named with another suffix must be associated with the scan rule as shown below.

    .ATTRIBUTE.%.suffix : .SCAN.idl

The .SOURCE.idl atom is used to define search directories for .idl files, including include files. The -I flags generated from the scan can be inserted into a variable as follows.

    IDLFLAGS &= $$(.INCLUDE. idl -I -I-)

There is no default build rule for IDL files due to variations in IDL compilers and their use by different projects. For details on using the IDL scan rule and building IDL code see the IDL FAQ on the nmake web site.

2.5 Multiple language support for -I-

A framework is now in place to support the scanning of multiple languages requiring -I- support. This includes a new, generalized .INCLUDE. function which generates include file search flags.

The optional third argument to .INCLUDE. specifies the -I- style flag used by the compile tool. When present, .INCLUDE. will return a list of search flags designed for -I- support, with the third argument separating the local include directories from the standard include directories in the search list. The default behavior of .INCLUDE. remains unchanged when the third argument is omitted.

Use the following to generate the -I flags for custom scan rules whose compile tools support -I-:

    xxFLAGS &= $$(.INCLUDE. <lang> -I -I-)

2.6 Prefixinclude for native preprocessors

The prefixinclude feature now has support for native preprocessors. When using a native preprocessor which supports -I- but not prefixinclude, nmake will add the necessary prefix directories to the -I search list on the compile command line to allow the native preprocessor to locate the headers in these directories.

The following example shows -Iinclude/abc added to the compile line while only include is part of the search directories defined by .SOURCE.h. File hello.c includes "abc/hello.h" which includes "h2.h" (also under abc/.) Note, when the nmake supplied preprocessor is used, -Iinclude/abc is not needed and is not added to the command line.

    .SOURCE.h : include
    hello :: hello.c

    $ nmake
    + cc -O -Iinclude -Iinclude/abc -I- -c hello.c
    + cc -O -o hello hello.o

2.7 Global version stamp in all binary executables

All binary executables in the nmake package are stamped with the nmake version string. This identifies which release each executable belongs to. Either the what or ident commands can be used to show the version string.

    $ what bin/nmake | grep make
    bin/nmake:
	    Lucent(R) nmake (Bell Labs) lu3.5 06/07/2002

    $ ident lib/cpp
    lib/cpp:
	 $Id: nmake:cpp (Bell Labs) lu3.5 06/07/2002 $
	 $Info: build on: SunOS 5.4 (lion.stc.lucent.com) $

3. Bug Fixes and Enhancements

3.1 Baserules

  1. 990054 - enhance prefixinclude for native preprocessors
    When using a native preprocessor that supports -I- but not prefixinclude, nmake will add necessary -I flags to the compile line so the preprocessor can find directory prefixed include files.
    See New Features: Prefixinclude for native preprocessors
  2. 990103 - adding shared lib prerequisite does not trigger relink
    Fixed a problem where adding a shared library as a prerequisite to an already made target would not relink the target. Now nmake relinks the target with the new prerequisite library as expected.
  3. 990105 - recurse messages enhancements
  4. 990136 - Investigate Orbix 3 idl -I- compiler problem
  5. 010003 - cannot link with shared lib when made in same makefile
    You can now build a shared library and link with it in the same makefile. Previous releases would bind to the archive library instead of the shared when linking.
  6. 010006 - .SYNCBEFORECCX should be .VIRTUAL
    The .SYNCBEFORECCX target is now properly defined as a .VIRTUAL target in the base rules.
  7. 010020 - makefile gets clobbered
  8. 010043 - nmake issues error when a user defined makerules is used
    When using a user defined makerules named something other than "makerules.mk", nmake would issue an error message on the second build. This has been corrected.
  9. 010044 - clobber will remove user defined makerules.mo
    nmake no longer deletes a local copy of makerules.mo when the clobber common action is specified.
  10. 010079 - force_shared=0 works the same as force_shared=1
    Setting force_shared=0 no longer turns on the force_shared feature. force_shared=0 will disable the feature if it was already enabled with force_shared=1. Setting force_shared=1 forces targets to relink when prerequisite shared libraries change.
  11. 010080 - CC.PRELINK should before -I list
    When defined in the probe file, the value of CC.PRELINK is now specified on the compile line before the -I flags. This is to support EDG based C++ compilers which require the flags in this order.

3.2 cpp

  1. 990111 - cpp recognizes too many flags
    In some situations a compiler flag will unintentionally activate a cpp option. For example, cpp will interpret the -compat=4 flag for Sun's C++ compiler as the cpp -compat flag to preprocess code on compatibility mode. This results in incorrect preprocessing for the target compiler. To avoid conflicts such as this ppcc now strips offending flags from the command line when calling cpp and only includes the flags when calling the compiler. The change was put in ppcc instead of cpp itself to insure cpp retains compatibility with current usage.
  2. 990120 - cpp ignores -U__STDC__
    cpp now allows the __STDC__ and __STDPP__ macros to be undefined using the -U flag in compatibility and transition modes when the macros are defined by default . A warning message is issued when in transition mode. In strict ANSI mode the macros are read-only and an error is generated.
  3. 990122 - cpp nested macro not expanded properly
    Corrected a problem where nested macros were expanded wrong in the ANSI dialect when the code contained a leading blank space before the macro #string.

3.3 Engine

  1. 990169 - file scanning-prefixinclude bug
    Fixed a bug that caused nmake, under rare circumstances, to skip a section of a file when scanning the file for prerequisites when prefixinclude=0. This would cause the implicit prerequisite list to be incomplete and/or incorrect. This fixes the problem of scanning perl.h.
  2. 990173 - :F edit operator shows %y year incorrectly
    Fixed a bug where the :F edit operator, which is used to format variable expansion, printed %y (the short-hand year) as three digits instead of two. This would, for example, result in year 102 instead of 02.
  3. 010014 - wrong rule is run when .JOINT target is meta-rule prerequisite
  4. 010046 - implicit headers can corrupt build
    Fixed a problem that would cause nmake to issue an error when searching for a non-existent include file that was ifdef'ed out of the code. The error occurred after the user changed source code to fix a legitimate error and reran nmake. If the include file was inside an ifdef block in another source file, and the nmake state file was not removed, nmake would still issue an error about the missing include file even after the source code was corrected.
  5. 020012 - core dump building shell script prerequisite
    Fixed a core dump that occurred when building a shell script that was a prerequisite to a .FUNCTIONAL target.

3.4 Operators

  1. 980003 - too many installs using both :INSTALLDIR: and :INSTALL:
    The install common action acted inconsistently depending on the order of the ::, :INSTALL:, and :INSTALLDIR: assertions in the makefile. For example, assuming the assertions are installing to different target directories or file names, defining an :INSTALLDIR: assertion followed by the corresponding :: assertion would result in a single install action. But defining the :: first and then :INSTALLDIR: would result in two installs. Similarly, defining assertions in the order of :INSTALLDIR:, :INSTALL:, and :: could result in three installs, while :INSTALLDIR:, ::, and :INSTALL: would result in two. The assertions have been modified so the :: assertion will not trigger an install when its target is also installed by :INSTALLDIR: or :INSTALL:. The assertions now give consistent results regardless of their sequence in the makefile.
    See also Changes impacting lu3.4 Makefiles: :INSTALL: and :INSTALLDIR:.
  2. 010001 - extend :: operator to make shared library
    Shared library targets can now be built with the :: operator.
    See New Features: :: operator support for building shared libraries.
  3. 010013 - :LIBRARY: omits prerequisite libraries from .req file
    When building a library with :LIBRARY:, shared library prerequisites were being left out of the library required file. Shared libraries are now included in the required file as expected. The required file is called name.req for library libname and is installed to file $(LIBDIR)/lib/name. When a target has a library prerequisite nmake reads the library's required file and automatically includes the listed libraries as prerequisites.
  4. 010024 - :ALL: convert alarm target to .ALARM
    Fixed a problem where specifying ":ALL: alarm" in a makefile would cause nmake to try to build .ALARM instead of a valid target named alarm. It is also fixed for targets named bind and sync.
  5. 010072 - :MAKE: does not like ../dir
    Fixed the :MAKE: operator to recurse to relative directories starting with ../. This worked in release lu3.3 but was broken in lu3.4.

3.5 Probe

  1. 990128 - CC.STDINCLUDE includes /usr/include/bits first
    On Linux® machines probe would include directory /usr/include/bits in the list of standard include directories. This causes errors when using nmake cpp because files should not be included directly from /usr/include/bits, they should only be included by other standard include files. Probe no longer includes /usr/include/bits in the list of standard include directories.
  2. 010015 - need paths canonicalized in probe files
    Under certain conditions the paths defined in the probe variables CC.STDINCLUDE and CC.STDLIB would contain one or more ../'s making them unnecessarily complex and difficult to read. The paths are now canonicalized, or simplified to remove occurrences of "../".
  3. 020007 - Solaris C++ 6U2 probe does not set CC.SUFFIX.SHARED
    The CC.SUFFIX.SHARED variable was incorrectly set to null for the Sun Solaris C++ 6u2 compiler. Probe now correctly detects the shared library suffix for this compiler.

3.6 Variables

  1. New base rules variable clobberignore - see 010020
  2. New default value for JAVACLASSDEST - see 020028
  3. Variable MAXJAVAC depreciated - see 020028
  4. Enhanced deafult for JDEPSDIR - see 020028
  5. New base rules variable JAVAPACKAGEROOT - see New Features: Java inside-package local build

3.7 Miscellaneous

  1. 020006 - global version stamp for all executables
    All binary executables are now stamped with a common version string.
    See New Features: Global version stamp in all binary executables
  2. 020028 - Java enhancements

4. Changes Impacting lu3.4 Makefiles

The changes in release lu3.5 are largely backward compatible with lu3.4. Every effort has been made to insure code changes do not unexpectedly change the documented behavior of nmake features.

A few enhancements did require small changes to functionality. These changes are described below.

  1. 980003 - too many installs using both :INSTALLDIR: and :INSTALL:
    Description
    The behavior of the install common action was inconsistent and dependent on the order of the ::, :INSTALL:, and :INSTALLDIR: assertions in the makefile. The assertions have been modified to give consistent results regardless of their sequence. Now the :: assertion will not trigger an install when its target is also installed by :INSTALLDIR: or :INSTALL:.
    See also Bug fixes and enhancements: 980003.
    Who is affected
    Projects expecting different installs from both the :: assertion and either :INSTALLDIR: or :INSTALL: within the same makefile. We expect this to be very rare.
    What to do
    Add an additional explicit :INSTALLDIR: operation to replace the :: default install.

     
  2. 990105 - recurse messages enhancements
    Description
    The recurse_begin_message and recurse_end_message variables no longer print the current subdirectory by default. Prior to release lu3.5 the value of the variable was prepended to the subdirectory name and printed when nmake recursed into and from a subdirectory via the :MAKE: operator. The current subdirectory is no longer printed by default making the variables more flexible. For example, the recurse messages can now be defined to print messages in the style of other build tools, which may allow integration with other tools that expect such output.
    See also Bug fixes and enhancements: 990105.
    Who is affected
    Anyone defining variables recurse_begin_message or recurse_end_message.
    What to do
    To print the current subdirectory as in prior releases include the variable $(RECURSE_MESSAGE) in the definition of recurse_begin_message and recurse_end_message. For example:
    recurse_begin_message = STARTING DIR $(RECURSE_MESSAGE)

     
  3. 020028 - Java inside-package local build
    Description
    The new variable JAVAPACKAGEROOT must be defined to use the :JAVA: operator. If JAVAPACKAGEROOT is undefined when building a makefile that uses :JAVA: nmake will return an error indicating JAVAPACKAGEROOT must be defined. Prior releases of nmake did not use this variable.
    See also New Features: Java inside-package local build.
    Who is affected
    Anyone using the official :JAVA: assertion. This does not include projects who have defined their own :JAVA:.
    What to do
    Define JAVAPACKAGEROOT as described in New Features: Java inside-package local build.


5. Known Problems and Remarks

5.1 Known Problems

The following is a list of known problems:

  1. AIX - The AIX package does not have the global version strings in the binary executables.
  2. HP-UX - HP's aCC compiler uses <include/file.h> to include the system headers so /usr must be part of the standard include search directories. However, probe does not currently detect this and such includes may cause errors. Also, some users have experienced run-time problems with shared libraries when using aCC due to nmake calling ld to make the shared library instead of aCC. Use the following in your probe_hints file to work-around these issues:
        case $CC_CC in
        *aCC) CC_STDINCLUDE="$CC_STDINCLUDE /usr"
    	  CC_LD="$CC_CC"
    	  CC_MEMBERS="\`\$(NM) \$(NMFLAGS) \$(*:N=*\$(CC.ARCHIVE):O=1) | \
    		      \$(SED) \$(NMEDIT) -e \"s/^/-Wl,-u/\"\`"
        ;;
        esac
  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 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.
  4. 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.

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.

Last Update: Friday,12-Aug-2016 12:32:03 EDT