Nokia Networks Home

Nokia nmake Product Builder

Quick Links

Related Products

Release Notes -- Nokia nmake lu3.8

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

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


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

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