Path: utzoo!utgpu!news-server.csri.toronto.edu!clyde.concordia.ca!uunet!samsung!sdd.hp.com!uakari.primate.wisc.edu!aplcen!haven!adm!smoke!gwyn
From: gwyn@smoke.BRL.MIL (Doug Gwyn)
Newsgroups: comp.unix.wizards
Subject: Re: But I don't wanna do non-blocking I/O...
Message-ID: <13147@smoke.BRL.MIL>
Date: 17 Jun 90 22:30:34 GMT
References: <1990Jun14.124906.18547@virtech.uucp> <409@minya.UUCP> <1990Jun17.123001.8299@virtech.uucp>
Organization: U.S. Army Ballistic Research Laboratory, APG, MD.
Lines: 20

In article <1990Jun17.123001.8299@virtech.uucp> cpcahil@virtech.UUCP (Conor P. Cahill) writes:
>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.

It sure didn't do a very good job the few times I tried it in a mixed
(System V emulation on 4BSD) environment.  That's the point that the
fellow who suggested keying on features rather than system types was
trying to get across.  There are far too many hybrid/merged systems
now for "System V" and "BSD" labels to mean much of anything when it
comes to deciding how to configure an application.

My solution has always been to develop all applications for a viable
subset of UNIX System V no matter what the target system; one way or
another it is possible to provide the expected System V environment
for the application, which pretty much avoids having to configure it
at all.  (This approach doesn't deal with facilities not found in the
minimal supportable System V environment, such as graphics and to
some extent networking, but those are areas in which other portability
solutions than #ifdefing should be devised anyway.)