Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm
Sender: cygwin-owner AT cygwin DOT com
Mail-Followup-To: cygwin AT cygwin DOT com
Message-ID: <3E54F29B.4000203@hekimian.com>
Date: Thu, 20 Feb 2003 10:22:03 -0500
From: Joe Buehler <jbuehler AT hekimian DOT com>
Reply-To: jbuehler AT hekimian DOT com
Organization: Spirent Communications, Inc.
User-Agent: Mozilla/5.0 (Windows; U; WinNT4.0; en-US; rv:1.3a) Gecko/20021212
MIME-Version: 1.0
To: Gershon Kagan <Gersh-k AT orbotech DOT com>
CC: cygwin AT cygwin DOT com
Subject: Re: Kudos
References: <1E81AA2AAE3DD51182030008C7BB9B3652AA9F AT excg-isl>
In-Reply-To: <1E81AA2AAE3DD51182030008C7BB9B3652AA9F@excg-isl>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit

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
> compare approaches.

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
the makefiles.

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).
-- 
Joe Buehler


--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Bug reporting:         http://cygwin.com/bugs.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/