Nokia

Nokia nmake Product Builder

 

Nokia nmake Product Builder
lu3.8 Release Notes

Table of Contents

Released: July 2006

1. Introduction
1.1 Supported Hardware
1.2 Hardware Requirements
1.3 Software Requirements
1.4 Customer Support

2. New Features and Significant Enhancements
2.1 Introduction of new platform support: Red Hat Enterprise Linux 3, Solaris 10
2.2 Improved support for Sun C++ 7.x and 8.x compilers
2.3 :JAVA: performance enhancements
2.4 Support for Java builds from a directory other than the source package directory
2.5 Java builds filter out #empty files
2.6 globaljavadeps and localjavadeps are synchronized via the state file
2.7 MS Visual C++ compiler supported on Windows/SFU
2.8 New environment variable UMASKCHANGE to disable umask change
2.9 nmakelog now compatible with :JAR: makefiles
2.10 Enhanced manifest file support for :JAR:
2.11 Multiple :JAR: makefiles can update the same target jar file

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

4. Changes Impacting lu3.7 Makefiles
4.1 :JAR: Appending to an Existing Jar File
4.2 disableumaskchange Option Deprecated
4.3 Required-libraries

5. Known Problems and Remarks
5.1 Known Problems
5.2 Remarks


1. Introduction

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

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

1.1 Supported Hardware

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

1.2 Hardware Requirements

1.3 Software Requirements

This release of nmake is available for HP-UX, Linux, Solaris, and Windows (under SFU/Interix). See the release lu3.8 download page for a listing of available distribution packages. nmake is generally upward compatible with later OS releases in a series (for example, the series Solaris 2.5 through 2.10); contact Technical Support with any compatibility questions or with any requests for porting to other systems.

The Windows-based version of nmake is based on the Windows Services for UNIX (SFU/Interix) porting/development environment from Microsoft and requires installation of the SFU package in order to run. The SFU package must be obtained from Microsoft and installed following their installation procedure. For more information see the Support for Windows page.

nmake lu3.8 provides dependency-based Java build support. This feature currently requires an external Java source scanner called JavaDeps to extract inter-modules dependencies from Java source. nmake lu3.8 requires JavaDeps release lu2.2.2; this version is downloadable from the nmake JavaDeps page. Installation instructions are also on that page. THIS PACKAGE IS ONLY REQUIRED BY PROJECTS PERFORMING JAVA BUILDS USING THE :JAVA: ASSERTION OPERATOR. JavaDeps release lu2.2.2 is itself written in Java; it requires jdk1.2.1 or higher version on its PATH in order to run. (Note that this does not restrict the project being built to jdk1.2.1 or higher.)

1.4 Customer Support

We provide patch support, where code changes are required, for the latest 2 point releases of nmake (currently releases lu3.8 and lu3.7). 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 and Significant Enhancements

2.1 Introduction of new platform support: Red Hat Enterprise Linux 3, Solaris 10

Release lu3.8 has been officially tested and verified on two additional platforms, Solaris 10 (sometimes referred to as 2.10) and Red Hat Enterprise Linux 3.

2.2 Improved support for Sun C++ 7.x and 8.x compilers

Support for Sun's SUNWCCh include rule has been enhanced and better supports the 7.x and 8.x compilers. The probe variable CC.SUFFIX.LINKHEADER has been added to list the system headers with versions ending with SUNWCCh so nmake can bind and scan the proper headers when scanning source code. Headers that are rewritten with the SUNWCCh rules are also now retained in the state file so they are known for subsequent builds.

2.3 :JAVA: performance enhancements

The Java rules have been optimized for the common case resulting in a significant performance improvement when processing large Java packages. Before the optimization a particular operation in the Java rules was observed to take about 24 minutes for a Java package of about 18,000 Java source files. After optimization this operation was actually eliminated for the common build resulting in a drastic reduction in time for processing the package.

A second optimization is user controllable using the maxjavawarn base rule variable. The variable contains the maximum number of Java source files in a Java package in order to determine and warn of source files that have been removed in an incremental build. The default is maxjavawarn=3000 meaning a Java package of 3000 or less source files will warn the user when Java source files are removed in an incremental build (since their old classes may still exist). The check is skipped and no warning issued if there are more than 3000 source files in the package. The package of 18,000 source files mentioned above took approximately 15 minutes to check for deleted files. Projects can set the maxjavawarn variable to emphasize either performance or the warning notice. Also see the :JAVA: manual page for information on maxjavawarn.

2.4 Support for Java builds from a directory other than the source package directory

The :JAVA operator now supports building Java code where the package root is in a different directory from the makefile and .SOURCE.java is used to locate the package root. Here is an example makefile:

/****  obj/Makefile  ****/
JAVABUILDDIR = $(VROOT)/obj
JAVAPACKAGEROOT = $(VROOT)/java
.SOURCE.java : $(JAVAPACKAGEROOT)
:JAVA:  com

2.5 Java builds filter out #empty files

Since Java source files are not typically listed in the makefile they cannot simply be removed from the makefile to be removed from the build. Deleting a Java source file will eliminate that file from a build. However, in a viewpathing situation where versions of the deleted file remain in other viewpathed nodes, those unwanted versions will still be picked up. The #empty feature provides a way to remove a Java file from a build and also mask out viewpathed files in other nodes.

The :JAVA: operator will filter Java source files containing the string "#empty" out of the build. The contents of a source file can be changed to "#empty", masking out old versions of the file in the viewpath, when it should no longer be built. Source files changed to "#empty" in an incremental build will have the contents of their class files changed to "#empty" effectively removing the class and masking out old versions in the viewpath.

The :JAR: operator will also exclude Java source files containing the string "#empty" when creating a jar archive of source files. By default class files are not scanned nor filtered to eliminate any performance impact for projects not using the feature. Class files can be filtered from jar archives by including the following in the makefile:

.ATTRIBUTE.%.class : .SCAN.java

See the :JAVA: and :JAR: manual pages for details.

2.6 globaljavadeps and localjavadeps are synchronized via the state file

Information for localjavadeps and globaljavadeps are now stored in the state file. If either file changes or is removed outside of nmake the file will be automatically regenerated to return it to a trusted state.

2.7 MS Visual C++ compiler supported on Windows/SFU

The Microsoft Visual C++ compiler is now supported on the Windows/SFU (Services for Unix/Interix) platform using the Interix /bin/cc compiler wrapper. The wrapper and environment must be configured according to Interix requirements.

2.8 New environment variable UMASKCHANGE to disable umask change

The disableumaskchange option name and -u command line option have been removed and replaced with the environment variable UMASKCHANGE. The change is due to the need to set the umask early in nmake startup before the options are read. UMASKCHANGE must be set in the environment not in the makefiles.

UMASKCHANGE may be 0/NO/no to suppress changing the umask to match the current directory permissions, or 1/YES/yes/null to change the umask. For compatibility the umask change is enabled by default. Any other UMASKCHANGE value generates a warning and keeps the umask change enabled.

2.9 nmakelog now compatible with :JAR: makefiles

The nmakelog output serializer is now compatible with :JAR: makefiles.

2.10 Enhanced manifest file support for :JAR:

The manifest file in a :JAR: assertion now triggers updates when the manifest file is touched or when a different manifest file is specified. If multiple manifest prerequisites are specified the first one is used and others are ignored with a warning message.

2.11 Multiple :JAR: makefiles can update the same target jar file

Multiple :JAR: makefiles can update the same target jar file by setting the new nmake variable jarappend=1. By default the jar target is recreated by each makefile thereby losing the archive members from the previous makefile. Set jarappend=1 in the makefile to add members to an existing jar without losing its contents.


3. Bug Fixes and Enhancements

3.1 Baserules

  1. 020009 - library rebuilt when node added to vpath
    Under certain conditions when a library was made and linked with an application in the same makefile, the library would be recompiled and the application re-linked when an empty node was added to the viewpath. This has been fixed so the library does not rebuild unless necessary.
  2. 030109 - missing ppcc -l flag causes compile errors
    Some C++ compilers were not getting the -l flag for ppcc which causes ppcc to drop the -I flags when calling the compiler when linking. This caused errors when the -I flags were needed for template instantiation. This has been fixed by passing the ppcc -l flag when the probe variable CC.DIALECT contains PTRIMPLICIT.
  3. 040002 - executable not re-linked when sharedlibvers=0
    A target executable was not re-linked with an updated shared library under the following conditions: the prerequisite library is built by the same makefile as the executable; the library is made using the double colon (::) operator; the variable sharedlibvers=0 is set. This is fixed so the executable is now re-linked as expected when force_shared=1.
  4. 040070 - clean does not remove object files on AIX
    The clean common action now removes .o files on AIX platforms.
  5. 040075 - non-prefixed header gets .PREFIXED attribute
    When using the quoteinclude prefix feature there were some false positives for headers that did not inherit a directory prefix. This is fixed by insuring only headers that actually inherit a prefix are given the .PREFIXED attribute.
  6. 040085 - scan engine support for SUNWCCh include file
    Improved support for Sun's SUNWCCh header rewriting rule when using Sun's C++ compiler so proper dependencies are tracked for the .SUNWCCh suffix header files. The new probe variable CC.SUFFIX.LINKHEADER has been added to support this, which contains the system headers with versions ending with SUNWCCh.
    See also - New Features and Enhancements: Improved support for Sun C++ 7.x and 8.x compilers
  7. 040099 - enable VC++ to build and link with shared library
    On Interix platforms linking with shared libraries is now supported when using the MS VC++ compiler via the Interix /bin/cc compiler wrapper. The compiler wrapper calls GNU ld automatically to do the linking since VC++ does not support it. GNU ld must be in the PATH.
    See also - New Features and Enhancements: MS Visual C++ compiler supported on Windows/SFU
  8. 050033 - profiled library bound down vpath instead of local node
    An executable was linked with an old archive library down the viewpath instead of the new version in the local node under the following conditions: :LIBRARY: was used to make the library; the executable was made from the same makefile as the library; and CCFLAGS contained -g. This has been fixed so the executable now links with the updated library in the local node.
  9. 050044 - core dump from corrupted rule
    Under rare conditions nmake would core dump when expanding an automatic variable that isn't associated with a target. The Makerules have been changed to guard against the problem.
  10. 050067 - SUNWCCh support looking for wrong file
    When building on Solaris 2.8 and the Sun Studio 8 C++ compiler, code including <new.h> would build fine the first time but give an error about not finding new.h.SUNWCCh in the second build. This was caused by new.h.SUNWCCh losing the .SUFFIX.INCLUDE attribute after the initial run. This has been fixed by retaining the .SUFFIX.INCLUDE in the state file so it can be used when binding the include files in subsequent builds.
  11. 060007 - +l Required Libraries
    The .REQUIRE.+l% function now returns +lname only for the parent required library. Previously all the required libraries were transformed from -l to +l which may not be appropriate and is error prone since additional archive libraries may be picked up that were not intended, including system libraries.
    See also - Changes Impacting lu3.7 Makefiles: Required-libraries

3.2 cpp

  1. 040087 - cpp recursion too deep error with no recursion
    Over 1000 instances of a macro would trigger the 'recursion too deep' error from nmake cpp even when no recursion was present. This has been fixed by incrementing the recursion counter only when it happens on the same line. The counter limit was also raised to LINE_MAX which is usually 2048 but may vary by platform.

3.3 Engine

  1. 040010 - :P=L=x resolves path to wrong level - :JAR: error
    The :P=L=x edit operator was resolving some files to the wrong viewpath node which resulted in an error from :JAR: complaining that files didn't begin with JARROOT. The problem occurred when a file down the viewpath, but not in the last node, was added to .SOURCE.pattern and then .SOURCE.pattern was cleared. Then :P=L=x returned the file when x was one level deeper in the viewpath than where the file really exists. This problem has been fixed.
  2. 040060 - core dump building Java code
    Fixed a core dump that come up under complicated, rare conditions.
  3. 040074 - install action triggered before target is built
    When using concurrency and when installing files using hard links, the install action for a target could be triggered before the target was updated during incremental builds. This has been fixed.
  4. 040084 - stuck in prefixinclude loop
    Fixed a problem where, under certain conditions nmake would hang in an infinite loop scanning the include files.
  5. 040095 - bad -I list on second run
    Under certain conditions a C/C++ source file would be needlessly recompiled with a different -I list, which could lead to an unexpected compile error during incremental builds. This has been fixed.
  6. 050006 - extraneous installs
    A problem was fixed where, under some rare conditions, a file would be re-installed in a new, clean viewpath node when everything was already up to date.
  7. 050063 - nmake runs vpath command during shell jobs
    Under certain conditions a command called "vpath" would be executed any time a shell job was run. This was a result of the -u/disableumaskchange option added in release lu3.7 (the option did not need to be set to see the problem). The disableumaskchange option has been deprecated and replaced with the UMASKCHANGE environment variable.
    See also - New Features and Enhancements: New environment variable UMASKCHANGE to disable umask change
    See also - Changes Impacting lu3.7 Makefiles: disableumaskchange Option Deprecated

3.4 Operators

  1. 030072 - globaljavadeps not regenerated when deleted
    The globaljavadeps file created by the :JAVA: operator is now regenerated if it is deleted outside of nmake. Additionally, both the localjavadeps and globaljavadeps files are now maintained by the state file and regenerated when necessary.
    See also - New Features and Enhancements: globaljavadeps and localjavadeps are synchronized via the state file
  2. 040007 - jar file gets out of sync with makefile
    Using the :JAR: operator an existing jar target file would be updated if it had no state information. For example, if an old jar was lying around, building it would append to it rather than regenerate it and could result in old, unwanted archive members in the jar. Now by default such jar files will be regenerated from scratch so the old contents are lost and only the members from the current build are archived. The old behavior can be restored by setting jarappend=1 which also allows multiple makefiles to maintain a single jar file.
    See also - New Features and Enhancements: Multiple :JAR: makefiles can update the same target jar file
    See also - Changes Impacting lu3.7 Makefiles: :JAR: Appending to an Existing Jar File
  3. 040009 - user JARFLAGS is ignored
    The :JAR: rules were initializing JARFLAGS to null thus erasing any user settings. JARFLAGS is no longer initialized and if set by the user :JAR: will add the flags to the jar operations.
  4. 040018 - error updating jar target after target is removed
    When using :JAR:, removing the jar target file without doing a clobber or removing the state file no longer causes an error on the next build.
  5. 040065 - jar index option does not work with full path
    The :JAR: operator indexed the jar file after generating it by running jar i /full-path/file.jar. This index operation would fail for some jar files that contain a manifest which defines Class-Path. This has been fixed by not generating the index with the full path to the jar but instead changing directory to the jar file and specifying the file name with no path information on the command line.
  6. 040081 - Java makefile does not clobber when no source files
    The clobber common action can now be run on :JAVA: makefiles that have no associated Java source files.
  7. 040092 - correct --vpath for jdeps
    The --vpath flag passed to JavaDeps by the :JAVA: operator has been changed to accommodate Javadeps release lu2.2.2. The path specified now is each viewpath root node (like the VPATH environment variable) instead of the current directory expanded through the viewpath.
  8. 040098 - VC++ generates wrong .req file
    The required libraries file generated by the :LIBRARY: operator is now correct when using the MS VC++ compiler on Interix.
    See also - New Features and Enhancements: MS Visual C++ compiler supported on Windows/SFU
  9. 050030 - provide filter for Java/Jar rules
    The :JAVA: and :JAR: operators now filter Java source files containing "#empty" out of the build. This can be used to mask old, unwanted Java files that still exist in the viewpath but should no longer be built.
    See also - New Features and Enhancements: Java builds filter out #empty files
  10. 050034 - support jdeps040018 Java builds in different directory
    Under certain conditions when using the :JAVA operator to build Java code located under a different directory from the makefile and using .SOURCE.java to locate the package root, each Java source file would be passed to JavaDeps multiple times, expanded once for each node in the viewpath. This has been fixed.
    See also - New Features and Enhancements: Support for Java builds from a directory other than the source package directory
  11. 050045 - :JAR: incompatible with nmakelog
    The :JAR: operator is now compatible with the nmakelog output serializer.
  12. 050053 - JAVA.mk error when touching generated class files
    When building Java code using the :JAVA: operator, Java packages with certain inner classes could result in an error from the touch command while the package was being prepared to be compiled. This was caused by some of the class directories not being created before touch was called and has been fixed.
  13. 050054 - JAVA.mk bottleneck
    Optimizations have been made to the :JAVA: operator which result in significant speed up for very large Java packages. The new maxjavawarn variable can be used to control part of the optimization.
    For details see - New Features and Enhancements: :JAVA: performance enhancements
  14. 050057 - :JAR: recurses when not necessary
    The :JAR: operator no longer recurses the directory tree for explicit files specified on the right hand side with no shell pattern. Since the file is explicitly identified the recursion is not necessary to locate the file. Previously this would cause large delays when specifying files at the top of a tree since all the sub-directories were needlessly searched. Now a recursion is triggered only when a shell pattern is specified somewhere in the path.
  15. 050061 - :JAR: enhancements
  16. 050062 - .JAVA.JDK error
    The :JAVA: operator no longer generates an unexpected error when JAVAC is defined with some command line flags (e.g., JAVAC = javac -g).
  17. 050066 - JARROOT error when JARROOT not in current vpath node
    An error no longer occurs when the JARROOT directory exists down the viewpath and not in the local build node.
  18. 060018 - jdeps called with no Java files
    Under certain conditions the :JAVA: operator would re-run JavaDeps without specifying any Java files when everything was up to date. This has been fixed so JavaDeps is not re-run.
  19. 060023 - .AFTERDONE not triggered
    Under certain conditions when using :JAVA: to build a large Java package with multiple batch compiles the last batch was not triggered resulting in an incomplete set of class files. This has been fixed.
  20. 060030 - JAR.mk JARROOT and clobber errors
    Some :JAR: fixes found in beta test. When two jar files are built in one makefile, the second jar includes the first jar and the jar targets are not in the current directory a JARROOT error occurred when updating the jars in a new viewpath node. Under the same conditions using the clobber common action would result in an unexpected error. Both issues have been fixed.

3.5 Probe

  1. 040038 - probe LD_LIBRARY_PATH test
    The probe script did not properly detect the compiler's use of LD_LIBRARY_PATH to include in the CC.STDLIB probe variable. This has been fixed.
  2. 040072 - probe scripts - /bin/cut not on all Linux platforms
    The probe scripts now call cut from the PATH instead of /bin/cut which may not exist on all platforms.
  3. 040086 - cpp defines needed for AIX compiler
    _LONG_LONG now is properly defined in the pp probe script for the AIX C compiler.
  4. 040091 - update probe scripts to support VC++ on Interix
    The probe scripts now support the MS VC++ compiler on Interix via the /bin/cc wrapper.
    See also - New Features and Enhancements: MS Visual C++ compiler supported on Windows/SFU

3.6 Miscellaneous

  1. 040089 - resolve lu3.7 gcc library dependencies
    The taglines and logfilter commands on Solaris no longer depend on the libstdc++.so and libgcc_s.so shared libraries.
  2. 050048 - bad iffe results with gcc -O optimize flag
    An iffe test related to static linking that was giving bad results when using the -O optimize flag with gcc and some other newer compilers has been fixed.

3.7 Variables

  1. New variable CC.SUFFIX.LINKHEADER - see 040085.
  2. New variable jarappend - see 040007.
  3. New variable maxjavawarn - see 050054.
  4. New variable UMASKCHANGE - see 050063.

3.8 Options

  1. Deprecated option -u / disableumaskchange - see 050063.

4. Changes Impacting lu3.7 Makefiles

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

The following may impact builds and require changes.

4.1 :JAR: Appending to an Existing Jar File

Description
In release lu3.8 a jar file that has no state information (e.g., a 3rd party jar, a jar file created by another makefile, the state files were removed) will no longer be appended by the :JAR: operator by default. Instead the file will be regenerated losing the old contents. This is a change in the default behavior in order to keep the jar file consistent with the state file.
Who is affected
Projects maintaining a single jar file in multiple makefiles or adding members to jar that is originally created outside of nmake.
What to do
To restore the old behavior and append to an existing jar file, set the variable jarappend=1 in your makefile.
See also
Bug Fixes and Enhancements: jar file gets out of sync with makefile

4.2 disableumaskchange Option Deprecated

Description
The -u / disableumaskchange option has been removed. The option introduced in release lu3.7 was used to prevent changing the umask to match the current directory permissions. The setup of the umask has to be done very early, before the options are parsed, so the option was replaced with an environment variable.
Who is affected
Anyone using the -u or disableumaskchange option.
What to do
Stop using the old option. To disable the umask change set the environment variable UMASKCHANGE=no (values 0 (zero) and NO are also accepted). The variable must be set in the shell environment not in the makefile.
See also
Bug Fixes and Enhancements: nmake runs vpath command during shell jobs

4.3 Required-libraries

Description
A change to the .REQUIRE.+l% function may change the way required-libs used from :LIBRARY: or CC.REQUIRED.name works. Previously when the parent required-lib was referenced as +lname all the required-libs were transformed to +l instead of using -l (+l is used to prefer archive libraries over shared libraries). This is error prone since additional archive libraries may be picked up that were not intended, including version specific system platform libraries which can break portability to later versions of the platform.
For example, say the following makefile was used to make libabc which depends on the libsocket system library:
$ cat lib.mk
CCFLAGS += $$(CC.PIC)
LIBDIR = lib
:ALL:
abc :LIBRARY: abc.c -lsocket
If +labc was specified as the prerequisite to an executable then its required-libs were also changed to +l, thus libsocket.a would be pulled in instead of -lsocket:
$ cat app.mk
.SOURCE.a : lib
hello :: hello.c +labc

$ nmake -f app.mk
+ cc -O -I- -c hello.c
+ cc -O -o hello hello.o lib/libabc.a /usr/lib/libsocket.a
With the new behavior, only the specified parent library is changed to +l so the libsocket shared library is pulled in:
$ cat app.mk  
.SOURCE.a : lib
hello :: hello.c +labc

$ nmake -f app.mk
+ cc -O -I- -c hello.c
+ cc -O -o hello hello.o lib/libabc.a -lsocket
Who is affected
Projects using +lname with required-libs to intentionally pick up archive libraries for all the required-libs.
What to do
If you want the required-libs to use +l you can define CC.REQUIRE.name when linking with libname to override the default required-libs. Or if you are already using CC.REQUIRE.name define it with +l libraries. For example, if you want libxyz to pull in +lx +ly +lz then defining the following when linking with libxyz:
CC.REQUIRE.xyz = -lxyz +lx +ly +lz
Specifying +lxyz or -lxyz as a prerequisite will automatically pull in +lx +ly +lz.
A second option is to define the old .REQUIRE.+l% rule in the project's local rules to restore the old behavior. This is discouraged since the project will need to maintain the rule.
.REQUIRE.+l% : .FUNCTION
    local L
    L := $(.REQUIRE.-l% $(%:/+l/-l/))
    return $(L:/-l/+l/:T=F)
An interesting solution would be the definition of required-libraries to use +l when the required-libs are originally specified as such on the :LIBRARY: assertion. This feature is not currently supported but is a candidate for inclusion in a future release.
See also
Bug Fixes and Enhancements: +l Required Libraries


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.

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