Path: utzoo!utgpu!news-server.csri.toronto.edu!clyde.concordia.ca!uunet!virtech!cpcahil
From: cpcahil@virtech.uucp (Conor P. Cahill)
Newsgroups: comp.unix.wizards
Subject: Re: But I don't wanna do non-blocking I/O...
Message-ID: <1990Jun17.123001.8299@virtech.uucp>
Date: 17 Jun 90 12:30:01 GMT
References: <397@minya.UUCP> <1990Jun12.203245.5804@virtech.uucp> <407@minya.UUCP> <1990Jun14.124906.18547@virtech.uucp> <409@minya.UUCP>
Reply-To: cpcahil@virtech.UUCP (Conor P. Cahill)
Organization: Virtual Technologies Inc., Sterling VA
Lines: 23

In article <409@minya.UUCP> jc@minya.UUCP (John Chambers) writes:
>
>My main problem with this is that it gets a bit clumsy as the list grows.
>Writing code that handles a variety of systems is a problem that doesn't
>seem to have been well-solved as yet.  (I expect to get lots of flames
>from the CASE crowd for that remark! ;-)

Actually it has been solved for quite a few systems/programs.  Larry Wall's
Configure program does a pretty good job at determining the capabilities
of a given system.  A few years ago (before I could spell USENET) I wrote
a similar package used to set all the #defines for an office automation
package that I was porting.  This made the porting job 10 times easier
since I no longer had to rumage around the code looking for #ifdef's with
SYSV or BSD.

The central include file that defines all the machine dependencies must
include an expanation for each #define that allows you to review it and
determine that the configuration script made the corrrect decisions.

-- 
Conor P. Cahill            (703)430-9247        Virtual Technologies, Inc.,
uunet!virtech!cpcahil                           46030 Manekin Plaza, Suite 160
                                                Sterling, VA 22170