http://www.bell-labs.com/project/nmake/newsletters/
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.
UMASKCHANGE to disable umask
change
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:
JAVAPACKAGEROOT too deep
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.
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.
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.
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 #includeint 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.
<<home / newsletters