Nokia nmake Product Builder
Customer Support Newsletter

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

Issue No. 23 - September 2006
Contacts
Articles
  1. nmake lu3.8 Released
  2. JavaDeps 2.2.2
  3. Call for suggestions for lu3.9 development cycle
  4. GCC 4.x -I- Update
  5. Separating source and generated objects using viewpathing
  6. Using MS Visual C++ on SFU/Interix

Alcatel-Lucent nmake lu3.8 Released

We are proud to announce the general availability of nmake release lu3.8 as of July, 2006. In all, there are almost 50 user visible enhancements and bug fixes including the following. See the lu3.8 release notes for full information about the release.

index

JavaDeps 2.2.2

A new JavaDeps lu2.2.2 release was also made available July, 2006. JavaDeps is an optional package and only required for projects building Java code using the nmake supplied :JAVA: operator. This release fixes the following issues:

index

Call for suggestions for lu3.9 development cycle

Several features are under consideration for the nmake lu3.9 development cycle. Possible directions include integration with Eclipse and tighter integration for Java builds. We welcome any input on development directions. Contact us at nmake@alcatel-lucent.com.

index

GCC 4.x -I- Update

In issue021 we reported that the -I- option had been depreciated in gcc 4.0 and replaced with the new -iquote option. After studying the new option we found that it was not a complete replacement for -I-. It appears the problem is now recognized by the gcc developers. There are a couple bug reports (19541, 27137) and a patch which might indicate gcc's direction for this issue.

The patch implements a proposed new option -ignore-source-dir to add the missing functionality. It does not appear to be in the current pre-release version of gcc 4.1 so we built local a version of gcc with the patch and tested it along with the existing -iquote option.

-ignore-source-dir
Inhibit the use of the current directory (where the current input file came from) as the first search directory for `#include "FILE"'.
-iquote DIR
Search DIR only for header files requested with `#include "FILE"'; they are not searched for `#include <FILE>', before all directories specified by `-I' and before the standard system directories.

Our initial testing confirms that -iquote and -ignore-source-dir behave as expected and when used together can replace the deprecated -I- option. The gcc bug reports provide no indication of if or when the patch will be accepted for an official release. We will continue to monitor the situation and plan support for these options if -ignore-source-dir is officially added.

index

Separating source and generated objects using viewpathing

It is often desirable to separate build products from project source. There are several development scenarios where this separation is useful: 1) When supporting multiple platforms, it allows separate generation of multiple platform-specific targets from the identical source. 2) It allows separation of project baseline builds from project integration builds while sharing baseline source to the extent possible. 3) It allows separate generation of build products from multiple compilers and compiler modes. 4) It allows multiple developers to run development builds while sharing up-to-date project sources as much as possible. On the other hand, while developing it is convenient to keep Makefiles, source, and generated objects in the same working directory to allow source edit, compile, and debug without having to change directories. The techniques described here support this development scenario as well.

There are many ways to organize projects supporting multiple platforms and compilation modes. We find the approach described here to be particularly straightforward, flexible, and robust.

A typical UNIX/Linux project build structure is:

$ROOT/
    src/
	Makefile
	global.mk
	cmd/
	    Makefile
	    cmd1/
		Makefile
		a.c
		b.c
	    cmd2/
		Makefile
		c.c
		e.c
	lib/
	    Makefile
	    lib1/
		Makefile
		f.c
		g.c
    bin/
    lib/

src/cmd/ contains source for commands. src/lib/ contains source for libraries. Commands and libraries are built and debugged in their respective source directories and installed in bin/ and lib/. Using this structure, typical nmake Makefiles are concisely expressed using source level assertions :: and :LIBRARY: :

src/global.mk:

/* install files here */
INSTALLROOT = $(VROOT)

src/Makefile:

include $(VROOT)/src/global.mk

:MAKE: lib - cmd

src/cmd/Makefile, src/lib/Makefile:

include $(VROOT)/src/global.mk

:MAKE: *

src/cmd/cmd1/Makefile:

include $(VROOT)/src/global.mk

cmd1 :: a.c b.c

We replicate this simple directory structure for the various project nodes used in the course of development. We might have a baseline source node, a baseline product node for each platform, an integration source node, integration build nodes for several platforms, and developer build nodes (sandbox nodes) under developer's home directories. Defining $VPATH is then sufficient to direct build output to the writable topmost node, while picking up sources and any objects from lower nodes. Reconfiguration is as simple as defining the appropriate $VPATH variable; no changes to Makefiles are required.

For the above example, considering cmd1/ only, the baseline source node contains a complete set of official project sources and might look like:

$OFF_SRC/
    src/
	global.mk
	Makefile
	cmd/
	    Makefile
	    cmd1/
		a.c
		b.c
		Makefile

Baseline product nodes, say for Solaris and HP, might look like:

$OFF_SUN5/
    src/
	cmd/
	    cmd1/
		a.o
		b.o
    bin/
	cmd1

$OFF_HP11/
    src/
	cmd/
	    cmd1/
		a.o
		b.o
    bin/
	cmd1

The baseline build for Solaris is run using:

export VPATH=$OFF_SUN5:$OFF_SRC
cd $OFF_SUN5/src
nmake install

In this build, the entire official project source node is read-only, all generated objects go under $OFF_SUN5. By re-setting VPATH appropriately and kicking off the build on an HP host, hp11 objects would go under $OFF_HP11.

The integration source node contains sources submitted to the project build by developers after completion of unit test. This node generally contains only the subset of project sources changed from the baseline source, for example:

$SUB_SRC/
    src/
	cmd/
	    cmd1/
		b.c

The integration build, say for Solaris, is run using:

export VPATH=$SUB_SUN5:$SUB_SRC:$OFF_SUN5:$OFF_SRC
cd $SUB_SUN5/src
nmake install

This build should be run frequently (possibly nightly) to verify that developer submissions do not break the build. This build shares baseline source and generated objects to the extent possible.

Each developer may have separate sandbox nodes under each developer $HOME. Developer nodes contain only modified sources and pick up the rest through viewpathing, so they are space efficient enough to allow separate and independent sandbox nodes for each development task. For example, a developer needing to modify a.c might have a node like:

$DEV1/
    src/
	cmd/
	    cmd1/
		a.c

To run a developer build:

export VPATH=$DEV1:$SUB_SUN5:$SUB_SRC:$OFF_SUN5:$OFF_SRC
cd $DEV1/src
nmake

This build would generate $DEV1/src/cmd/cmd1/a.o and $DEV1/src/cmd/cmd1/cmd1.

Sometimes it is desirable for a developer to omit objects and do a clean build of the current submitted project source (perhaps with variant compiler options or a different compiler). This is accomplished through a simple change to the VPATH:

export VPATH=$DEV1:$SUB_SRC:$OFF_SRC
cd $DEV1/src
nmake

On projects supporting multiple platforms, a developer might want to build and test generated objects for more than 1 platform using the same set of local code changes. This can be accomplished with additional nodes under the developer's home directory: a single developer source node and a developer object node for each target platform. The developer would put changed source under $DEV1_SRC. To run a developer build for the Sun, the developer would do:

export VPATH=$DEV1_SUN5:$DEV1_SRC:$SUB_SUN5:$SUB_SRC:$OFF_SUN5:$OFF_SRC
cd $DEV1_SUN5/src
nmake

To summarize, we have presented an approach to separation of project sources and generated objects using viewpathing. Key advantages of this approach are:

See chapter 10 of the nmake User's Guide for more discussion on viewpathing.

index

Using MS Visual C++ on SFU/Interix

Release lu3.8 supports the MS Visual C++ compiler on Windows/SFU (Microsoft Services for UNIX) platforms. This allows the use of the native Microsoft compiler using the SFU/Interix /bin/cc compiler wrapper. The environment must be properly configured for the wrapper. Here is a quick guide to get started with SFU 3.5.

Set INTERIX_COMPILERDIR in the environment to the directory where VC++ is installed. For our Visual Studio .NET installation the directory is "/dev/fs/C/Program Files/Microsoft Visual Studio .NET/Vc7". But use the corresponding DOS 8.3 style path to avoid spaces in the path which appear to cause problems.

INTERIX_COMPILERDIR=/dev/fs/C/PROGRA~1/MICROS~1.NET

It is recommended to set this as a Windows system variable so it is defined when you login because the Interix /etc/profile checks the variable to setup the proper PATH. If it isn't a system variable then export it in the environment and then source /etc/profile to complete the setup.

$ export INTERIX_COMPILERDIR=/dev/fs/C/PROGRA~1/MICROS~1.NET

$ . /etc/profile
Welcome to the Interix UNIX utilities.

DISPLAY=localhost:0.0

Now you should be able to use /bin/cc.

$ cat hello.c
#include 
int main(){
    printf("hello worlds\n");
    return(0);
}

$ /bin/cc -o hello hello.c

$ ./hello
hello worlds

Set C89_ECHO=1 to see what commands the wrapper is calling.

$ C89_ECHO=1 /bin/cc -o hello hello.c
/dev/fs/C/PROGRA~1/MICROS~1.NET/Vc7/bin/cl.exe /c /IC:\SFU\usr\include /Ze /nolo
go /D__OPENNT /D__INTERIX /U_WIN32 /Dunix /D_ALL_SOURCE /D__STDC__ /Fohello.o C:
\SFU\home\richb\hello.c
LIB=C:\SFU\usr\lib  /dev/fs/C/PROGRA~1/MICROS~1.NET/Vc7/bin/link.exe /subsystem:
posix /nologo /nodefaultlib /ignore:4078 /heap:8388608,32768 /stack:4194304,6553
6 /entry:__PosixProcessStartup /merge:.CRT=.rdata /out:hello crt0.o hello.o libc
.a libpsxdll.a

The compiler wrapper can be used with nmake as expected:

$ cat Makefile
CC = /bin/cc
hello :: hello.c

$ nmake
probing C language processor /bin/cc for make information
probing C language processor /bin/cc for pp information
+ ppcc /opt/nmake.lu3.8/lib/cpp /bin/cc -O -I-D/opt/nmake.lu3.8/lib/probe/C/pp/B
3A01E21.bincc -I- -c hello.c
+ ppcc /opt/nmake.lu3.8/lib/cpp /bin/cc -O -o hello hello.o

See the Interix cc(1) man page for more information on the compiler wrapper.

index

<<home / newsletters