Nokia nmake Product Builder
Customer Support Newsletter

Issue No. 2 - January 24, 1999
http://www.bell-labs.com/project/nmake/newsletters/
In This Issue
Highlights
Technical Notes
Tidbits

Bell Labs China

We would like to take this opportunity to address some inquiries we have had regarding the STC's plans for the nmake product. In 1999 we will be expanding the development team to include staff members from Bell Labs China. However, responsibility for the product will be not moving.

The STC will continue to be responsible for the future direction, support, sales and development of the product. The developers from Bell Labs China will be learning about the tool and will help with the development of new features for the product (as a matter of fact they will be working on some of the features for the upcoming lu3.2 release).

     [index]

New Manuals Available

As we promised in the last issue, the new nmake manuals are ready for user consumption. The new manual set, released October of 1998, consists of two manuals: the nmake User's Guide and the nmake Reference Manual. They are available in both PDF and Postscript formats and can be downloaded from our documentation web page.

The PDF files are completely indexed and searchable and are great for on-line reference when using Adobe Acrobat Reader. The Postscript files are provided for hard-copy purposes for those who prefer Postscript. The STC will no longer be providing hard-copies of the manuals, the only way to get them is by download.

     [index]

nmake Release lu3.2

The development team is currently working on the next release of nmake to be called version lu3.2. This release will offer some new features, around 30 MR fixes to 3.1.2, and is scheduled for release 2Q99.

The planned new features include the following:

As always, it will be available for download when it is complete. Watch our web site for the availability announcement and full release notes.

     [index]

Year 2000

As if you don't hear about the year 2000 enough, we're going to keep reminding you about it in this newletter until the big date hits.

The official Y2K-compliant version 3.1.2 dated 07/01/1998. There is an older version of 3.1.2 dated prior to 07/01/1998 which was built on non-y2k-compilent versions of the various operating systems. Only 3.1.2 versions dated 07/01/1998 or later were compiled on y2k-complient operating systems and are officially supported as y2k-complient.

For more information on our year 2000 policy see the nmake year 2000 faq. The year 2000 build of 3.1.2 can be downloaded from the nmake download page.

     [index]

Testers Wanted for New Output Serialization Feature

Have you tried using nmake's parallel jobs features (-j jobs or coshell) but gave up due to hard to read build output? It is a well known problem when using these features the build output becomes very difficult or impossible to decipher. This happens because when you have several compiles or nmake processes running at the same time the output from all the compiles gets mixed together, you cannot tell which output goes with which command line and worse, which errors go with which specific compiles.

The development team is working on an output serialization feature to address this problem for the next release. The feature will reconstruct the build output (on the fly) so it is human readable again. We are looking for people interested in beta test this feature. You will not need to upgrade to the next release for testing purposes, but instead will use a modified 3.1.2 with the serialization support. Changes for this feature include small changes to the engine, some new rules in Makerules.mk, and a couple new commands in the nmake bin.

If you are interested in beta testing or more information on this feature please send a note to nmake@alcatel-lucent.com and let us know!

     [index]

HP cfront C++

If you are using HP's cfront based C++ compiler (not aCC) then please read on... We had several users having problems with this compiler and decided to contact HP to try to work out the issues. The general problem we see are errors similar to the following:

CC: error: header cache out of date in read-only repository
/home/bugati/richb/build/v3/src/ptrepository/gt__FiT1.he (-I changed) (727)

It turns out HP's cfront compiler does not work the same as Lucent's C++ 3.0.3 cfront compiler. When given multiple -ptr arguments to search ptrepository directories down the viewpath, the Lucent compiler will use objects from the secondary repositories that are up-to-date and rebuild out-of-date objects in the primary repository. However, when the HP compiler deems an object out-of-date in a secondary repository it issues an error as above.

Basically this means you can not take advantage of prebuilt repositories down the viewpath. We are suggesting projects migrate off HP's cfront compiler. Here is a quote from HP support:

This compiler is at the end of its life cycle. The lab will only fix critical errors at this point. If your company would like to pursue a business case for this being a critical error we may get the lab to make a change, but its sounds like it would result in a significant change in behavior, so I wouldn't be too hopeful of that approach.

HP's aCC and Lucent's C++ 4.1 compilers are highly recommended. Lucent's 4.1 compiler provides a C++ 3.0.3 language compatibility mode to ease migration of cfront-based programs to a modern C++ compiler. Lucent's C++ 3.0.3 is available for those in need of a cfront based compiler. We are also providing a work-around to use nmake with HP's cfront C++ compiler without getting the repository cache errors. The work-around and all information regarding the problem can be found in our HP cfront C++ faq.

     [index]

Gnu make vs. nmake

Many people have asked us how nmake compares with gmake, the popular gnu make utility. We have put together comparison charts of the two tools and added it to the nmake FAQ on our web site. Check it out!

     [index]

Compiling C and C++ Code in the Same Makefile

This tidbit explains the proper way to compile both C and C++ code in the same Makefile. Note that nmake does not use the filename suffix (ie. .c vs. .cc) to distinguish between C and C++ code! If you devise your own method to compile both file types (ie. by redefining meta rules or using custom action blocks, etc.) then it is very likely you will pick up the wrong probe files for one of the compilers which could easily lead to compile problems.

To compile both C and C++ code you need to call two different compilers, the C compiler and the C++ compiler. If you have a single compiler that handles both C and C++ code you are not off the hook, we'll talk about this special case the next issue...

For nmake to properly call the two compilers you need to use three things in your makefile:

  1. The $(CC) variable (upper-case): Identifies your C++ compiler. Set CC equal to the C++ compiler you wish to use. For example:
    CC = /opt/C++/bin/CC
  2. The $(cc) variable (lower-case): Identifies your regular C compiler. Set cc equal to the C compiler you with to use. For example:
    cc = /bin/cc
  3. The :cc: operator (lower-case): Identifies the code to compile with $(cc) (ie. the C compiler). List your regular C code on the right-hand-side of :cc:. For example:
    :cc: one.c two.c three.c

Example 1. A short example makefile would look as follows. In this example one.c and three.c are C code, two.c and four.c are C++ code. Notice both the C and C++ files are using the same filename suffix. In the build output you can see cc being called to compile the C code and CC for the C++ code. You will also see different -I-D/path/file arguments used for each compiler, indicating nmake is using different probe files as appropriate.

/* both compilers are in the path, otherwise use full path names. */
CC = CC
cc = cc
 
:ALL: test
 
test :: one.c two.c three.c four.c
 
:cc: one.c three.c


$ nmake
+ ppcc -i /tools/nmake/sparc5/v3.1.2/lib/cpp cc -O -I-D/tools/nmake/sparc5/v3
.1.2/lib/probe/C/pp/D586199Dobincc -I- -c one.c
+ ppcc -i /tools/nmake/sparc5/v3.1.2/lib/cpp cc -O -I-D/tools/nmake/sparc5/v3
.1.2/lib/probe/C/pp/D586199Dobincc -I- -c three.c
+ ppcc -i -l /tools/nmake/sparc5/v3.1.2/lib/cpp CC -O -I-D/tools/nmake/sparc5
/v3.1.2/lib/probe/C/pp/5CBE7E5DobinCC -I- -c two.c
template manager : Warning: No valid template database available.  Creating d
efault repository "Templates.DB".
+ ppcc -i -l /tools/nmake/sparc5/v3.1.2/lib/cpp CC -O -I-D/tools/nmake/sparc5
/v3.1.2/lib/probe/C/pp/5CBE7E5DobinCC -I- -c four.c
+ ppcc -i -l /tools/nmake/sparc5/v3.1.2/lib/cpp CC -O -I-D/tools/nmake/sparc5
/v3.1.2/lib/probe/C/pp/5CBE7E5DobinCC -I- -o test one.o two.o three.o four.o

Example 2. In the next example we will show how you can identify the C files automatically if you are using different filename suffixes for your C and C++ files. This example is the same as above except the filenames: one.c and three.c are C files, two.C and four.C are C++ files. Again notice the proper compiler is being called and the different -I-D arguments.

/* both compilers are in the path, otherwise use full path name. */
CC = CC
cc = cc
 
FILES = one.c two.C three.c four.C
ccFILES = $(FILES:N=*.c) /* use :N variable editor to match the .c C code */
 
:ALL: test
 
test :: $(FILES)
 
:cc: $(ccFILES)


$ nmake
+ ppcc -i /tools/nmake/sparc5/v3.1.2/lib/cpp cc -O -I-D/tools/nmake/sparc5/v3  
.1.2/lib/probe/C/pp/D586199Dobincc -I- -c one.c
+ ppcc -i /tools/nmake/sparc5/v3.1.2/lib/cpp cc -O -I-D/tools/nmake/sparc5/v3
.1.2/lib/probe/C/pp/D586199Dobincc -I- -c three.c
+ ppcc -i -l /tools/nmake/sparc5/v3.1.2/lib/cpp CC -O -I-D/tools/nmake/sparc5
/v3.1.2/lib/probe/C/pp/5CBE7E5DobinCC -I- -c two.C
template manager : Warning: No valid template database available.  Creating d
efault repository "Templates.DB".
+ ppcc -i -l /tools/nmake/sparc5/v3.1.2/lib/cpp CC -O -I-D/tools/nmake/sparc5
/v3.1.2/lib/probe/C/pp/5CBE7E5DobinCC -I- -c four.C
+ ppcc -i -l /tools/nmake/sparc5/v3.1.2/lib/cpp CC -O -I-D/tools/nmake/sparc5
/v3.1.2/lib/probe/C/pp/5CBE7E5DobinCC -I- -o test one.o two.o three.o four.o

     [index]

The rules statement and the MAKERULES, MAKERULESPATH engine environment variables

By using the rules statement, the default base rules can be overridden and allow alternate names to be given. For example, given the statement rules "myrules" on the first line of the first makefile, nmake will attempt to use the file "myrules.mo" as the makefile's base rules, and bind via the directory prerequisites of the .SOURCE.mk Special Atom. This operation is referred to as setting an alternate base rules context for the makefile. In addition, once a makefile is compiled into a make object file, the alternate rules should also be correctly specified by having the engine environment variable MAKERULES set to that file name in the environment. In the preceding example, this would mean having a variable "MAKERULES=myrules" in the environment. If not present, "MAKERULES=makerules" is assumed by default.

It is also useful to examine the default settings of both the MAKERULESPATH environment variable and the .SOURCE.mk Special Atom, since they affect the directory search order when locating custom base rules:

MAKERULESPATH = $(LOCALRULESPATH):$(MAKELOCALPATH):$(INSTALLROOT|HOME)/lib/make:
$(PATH:/:/ /G:D:B=lib/make:@/ /:/G):$(MAKELIB):/usr/local/lib/make:/usr/lib/make

.SOURCE.mk : . $(-file:/:/ /:D) $(-:N=-I[!-]*:/-I//) $(MAKERULESPATH:/:/ /G:T=F)

As shown, nmake attempts to be "smart" in its choice of search directories for .SOURCE.mk, which in addition to the directories in $(MAKERULESPATH), includes the current directory, the directory of the makefile specified via the -f command-line option (if given), and the directories used for locating include files.

The MAKERULESPATH default setting is viewable by examining the "Variables" section in a makefile's corresponding make object file. The .SOURCE.mk is internally set by the engine source code. By understanding these settings, more efficient use of this tool can be realized when custom base rules are used.

     [index]

The Solaris Debugger and nmake ppcc

Have you tried using the Solaris debugger only to find the debugger cannot locate your source files because it expects to find some .i file?

This happens because:

  1. nmake uses ppcc with the Solaris compiler. ppcc calls nmake cpp to create a preprocessed .i file and then passes the .i to the compiler.
  2. The Sparcworks C++ compiler doesn't use the filename specified in the preprocessed file, but uses the filename given on the command line instead, which in this case is the .i file generated from nmake cpp.

To get around this problem we have a modified ppcc script which can be used with the Solaris C++ compiler. The modified script can be downloaded from our Solaris debugger faq where you will also find usage instructions and a full explanation of the problem.

     [index]

Newsletter Feedback

We are looking for 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