Nokia nmake Product Builder
Customer Support Newsletter

http://www.bell-labs.com/project/nmake/newsletters/

Issue No. 10 - December 26, 2001
Highlights
  1. nmake lu3.4 patch 01
  2. JavaDeps Update
  3. Mailing List Update
  4. Newsletter Feedback
Technical Notes
  1. Java Support Enhancements
  2. nmake Statements vs. Shell Statements
Tidbits
  1. Local Probe
  2. Specifying Variable Edit Operators
Contacts
email: nmake@alcatel-lucent.com (tech support)
email: software@alcatel-lucent.com (licenses/orders)
web: http://www.bell-labs.com/project/nmake/


Highlights

Alcatel-Lucent nmake lu3.4 patch 01

Patch level 01 for lu3.4 is now available for download. The patch overlays lu3.4. Installation is automated and includes an option to back-out the patch and restore your nmake installation to its previous state. For details see the lu3.4-p01 patch page.

The following files are affected:

Here is a summary of the lu3.4-p01 fixes:

index

JavaDeps Update

A JavaDeps update release, JavaDeps-lu2.0.1, coincides with the lu3.4-p01 patch release. Although the JavaDeps update does not require the lu3.4 patch, we have made some java related fixes in lu3.4 so we recommend upgrading both. For details see the JavaDeps page.

The JavaDeps update includes the following fixes:

index

Mailing List Update

The nmake-announce mailing list was recently moved to a new mailing list server (both hardware and software). All members of the list were migrated to the new server. The procedures for subscribing and unsubscribing have changed slightly.

Join the list by sending email to listserv@alcatel-lucent.com with only the following text in the body of the mail message:

    subscribe nmake-announce your-name

Leave the list by sending email to the same address with only the following in the message body:

    signoff nmake-announce

index


Technical Notes

Java Support Enhancements

In the last issue we promised more details on future java support. The most recent work has been for the lu3.4-p01 patch and JavaDeps-lu2.0.1 releases, so it seems appropriate to discuss these changes. As of these releases all known problems in the java support have been resolved.

:JAVA:

The :JAVA: operator had several fixes applied in the patch. Most of the changes affect how javadeps was being called. In some cases a .java file was listed multiple times, once for each occurrence in the viewpath, on the javadeps command line. Besides being incorrect, this caused problems with the javadeps processing. This has been fixed so only the first such file found in the viewpath is included on the command line, as one would normally expect.

There were also situations where .java files down the viewpath would cause incorrect dependency assertions in the localjavadeps file. The assertion would contain an incorrect relative path to the prerequisite .java file, which of course caused problems with the dependencies. This has been resolved by changing the way the --vpath argument to javadeps is specified.

Another less critical, but annoying problem was that running 'nmake clobber' or 'nmake clean' would cause localjavadeps to be generated if it did not already exist. Since one does not typically expect to generate files when running clean or clobber this has been changed.

JavaDeps

Updates have also been made to javadeps. The original implementation used a string array for the classpath which limited it to 20 items. If you have more than 20 directories in the classpath then you would get errors from javadeps. This has been changed to use a vector type so there is no hard size limit to the classpath. And though we never saw a problem with the viewpath, the same change was made for viewpath handling.

For HP-UX users the most significant change to javadeps may be that javadeps no longer hangs with HP's Java 1.3.

The Future

For the future we are planning local package build enhancements to allow developers to build only specific packages (or sub-packages) to help speed up development for large java projects. You should also keep in mind we may add a required argument to the left-hand-side of :JAVA:. At present nothing is required on the left, but it would be best to specify "." to maintain compatibility with future changes, as was described in our previous java article.

index

nmake Statements vs. Shell Statements

nmake provides a large degree of programmatic control over the entire makefile. This control includes the ability to define both string and integer variables and to specify overall flow-control statements. At the same time, nmake also supports shell statements inside action blocks.

Let's start with an example:

target :
	FILES="a.c b.c"
	echo FILES is $(FILES)


$ nmake
+ FILES=a.c b.c
+ echo FILES is
FILES is

Before passing an action block to the shell, nmake variables are expanded. On the first line of the action block, FILES is defined. Since this is in the shell action it will be sent to the shell so FILES is purely a shell variable. The second line references $(FILES) as an nmake variable. Since FILES is defined in the shell, nmake expands $(FILES) to null before sending the action to the shell.

Let's change $(FILES) to ${FILES} and run nmake again.

target :
	FILES="a.c b.c"
	echo FILES is ${FILES}


$ nmake
+ FILES=a.c b.c
+ echo FILES is a.c b.c
FILES is a.c b.c

Now ${FILES} is a shell variable and will not be expanded by nmake. The shell expands it as expected.

Now let's rewrite this rule using nmake statements. First, add the .MAKE special atom in the prerequisite list so the statements in the action block are interpreted by nmake instead of the shell. You don't need to specify .MAKE when using assertion operators such as :FUNCTION: and :COMMAND: since these are defined in Makerules.mk with the .MAKE atom already. Second, change the variable ${FILES} to the format acceptable to nmake, $(FILES). Finally, replace echo with print because echo is not supported by nmake. Here is our result:

target : .MAKE
	FILES = a.c b.c
	print FILES is $(FILES)


$ nmake
FILES is a.c b.c

Let's look at another example:

targ :
	VAR=aaa

.DONE :
	: print VAR = $(VAR)


$ nmake
+ VAR=aaa
+ : print VAR =

In the above example, the variable VAR is set in a shell action block. Since VAR is only set inside the shell action $(VAR) expands to null in the .DONE action.

After adding .MAKE to the targ prerequisite list, we get:

targ : .MAKE
	VAR=aaa

.DONE :
	: print VAR = $(VAR)


$ nmake
+ : print VAR = aaa

Now VAR is defined as an nmake variable since the action block for targ is handled by nmake. VAR can now be expanded in the .DONE action. By default, the scope of nmake variables is global.

Here the differences between nmake and shell are highlighted.

nmake if shell if
    if expression_1
	    statement_1
    elif expression_2
	    statement_2
    else
	    statement_3
    end
    
    if expression_1
    then
            statement_1
    elif expression_2
    then
            statement_2
    else
            statement_3
    fi
    
nmake while shell while
    while expression
            statements
            ...
    end
    
    while expression
    do
            statements
            ...
    done
    
nmake for shell for
    for i item1 item2 item3
            statements
            ...
    end
    
    for i in item1 item2 item3
    do
            statements
            ...
    done
    

index


Tidbits

Local Probe

The local probe feature was added in release lu3.2. This feature can be useful if you ever want to experiment with different probe settings by changing the probe files. Using local probe you can create personal probe files that will be owned and referenced only by you. You can edit your local probe files without affecting other developers or builds.

The local probe feature supports two different modes. The easiest way to get started would be to use the vpath mode. When you set localprobe=vpath nmake will check the viewpath for probe files under $(VROOT)/lib/probe/C/make/ and $(VROOT)/lib/probe/C/pp/. If none exist in the viewpath then they will be generated in the top node.

$ nmake localprobe=vpath
+ probe -k C make /bin/CC
+ mkdir -p ../../v1/lib/probe/C/make
+ 2> /dev/null
+ chmod 0775 ../../v1/lib/probe/C/make
+ [ !  ]
probing C language processor /bin/CC for make information
+ probe -k C pp /bin/CC
+ mkdir -p ../../v1/lib/probe/C/pp
+ 2> /dev/null
+ chmod 0775 ../../v1/lib/probe/C/pp
+ [ !  ]
probing C language processor /bin/CC for pp information
...rest of build output...

You can now edit and experiment with your personal probe files. As long as you set localprobe=vpath you will pick up your files instead of the default. Note that the pp probe file may not be generated depending on your compiler and your nmake configuration.

The other local probe mode allows you to search a defined PROBEPATH for probe files. Set localprobe=1 and define PROBEPATH as a colon separated list of directories.

index

Specifying Variable Edit Operators

Typically, variable edit operators are specified using a colon (:) directly before the operator and after the variable name. For example:

    $(VAR:N=*.c)

It is possible to use another character in place of the colon. This is useful when a colon is being used with some edit operations. Specify an alternate character using a single back-quote followed by the replacement edit character in the first edit operation.

The following example shows a case where we want to use colon in the edit operation to match tokens in the variable that contain a colon. First we can see how this does not work when a colon is used to specify the edit operator:

VAR = :itchy :scratchy crusty

targ: .MAKE
	print $(VAR:N=*:*)


$ nmake
make: "targ", line 1: warning: unknown edit operator `*'

We can rewrite the edit operation to use a semi-colon to specify the operator:

VAR = :itchy :scratchy crusty

targ: .MAKE
	print $(VAR`;N=*:*)


$ nmake
:itchy :scratchy

If more than one edit operation will be strung together then the replacement character must be defined in the first edit operator and it must be used for all subsequence edit operators. You cannot redefine the character part way through the edit list.

index


Newsletter Feedback

We are always interested in feedback! Let us know what you think of the newsletter, how we may improve, or ideas you have for future issues. Send us a note at nmake@alcatel-lucent.com. All ideas, suggestions, and comments are welcome.

index

<<home / newsletters