This is the mail archive of the
mailing list for the Cygwin project.
- From: Joe Buehler <jbuehler at hekimian dot com>
- To: Gershon Kagan <Gersh-k at orbotech dot com>
- Cc: cygwin at cygwin dot com
- Date: Thu, 20 Feb 2003 10:22:03 -0500
- Subject: Re: Kudos
- Organization: Spirent Communications, Inc.
- References: <1E81AA2AAE3DD51182030008C7BB9B3652AA9F@excg-isl>
- Reply-to: jbuehler at hekimian dot com
Gershon Kagan wrote:
Do you use make in a GNU emacs X window on both platforms for an
identical build interface? Do you use gcc on both platforms or MS
Visual C++ ? How do your makefiles support multiple platforms?
I wrote some templates that generate Makefiles that use make variables
to support the native compiler on multiple platforms. I just wanted to
I use emacs for maintenance work and fixing build problems. The builds
are automated, with a status monitoring system that reports on builds
in real time to a database server that distributes the information to
Java GUI clients, so developers can see whether their build worked
and what kinds of errors have been detected.
We use AT&T nmake with native compilers on all platforms (xlC on AIX,
cc/aCC on HPUX, cc/CC on SUNOS, msvc++ 5/6 on Windows). AT&T nmake is
vastly superior to GNU make feature-wise. I think it was originally
written for performance reasons, to reduce the AT&T 5ESS switch build
times, which were taking several days back in the 80's.
The cross-platform abilities are a major reason we use it -- we use
the same ksh build scripts and same makefiles on all machines. There are
some conditionals for platform tests, but it is minimal because of the
rule set we have running on top of the nmake engine (we don't use
the rule set that comes with nmake). Basically, we developed a set
of functions that get used in the makefiles. Like this:
temp.exe :make: file1.c file2.cpp libwhatever.a
The :make: function takes care of filename translation (libwhatever.a
becomes libewhatever.lib on a Windows box) and generation of all the
make rules and shell command blocks to generate temp.exe, build lint
for it, export it into an export area, etc. If we want to add something,
we just change :make: in the master rules file and don't have to touch
Parallel build performance is another reason we use it. GNU make can
do parallel builds, but it does not have any mutual exclusion capabilities
built in for rules that conflict with one another -- nmake does.
Then there's automatic header file scanning, compiled makefiles (for speed),
state retention between builds (also for speed), viewpathing (for multiple
developers working against a shared baseline build), much simplified makefiles,
and probably a few other things that don't occur to me at the moment.
Oh, yes, shell command blocks are just that, blocks -- they are not
executed one line per shell and you don't need those awful \ characters
to continue lines. Multimachine network builds are supported also,
though we don't use that (yet).
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Bug reporting: http://cygwin.com/bugs.html