Path: utzoo!attcan!uunet!codonics!bret
From: bret@codonics.COM (Bret Orsburn)
Newsgroups: comp.windows.x
Subject: Re: #ifdef in Xlibos.h
Message-ID: <1305@codonics.COM>
Date: 13 Apr 90 05:28:07 GMT
References: <5594@scolex.sco.COM> <9004111514.AA11945@kanga.lcs.mit.edu> <90Apr12.014138edt.3569@smoke.cs.toronto.edu>
Organization: Codonics, Inc., Middleburg Heights, OH
Lines: 43

In article <90Apr12.014138edt.3569@smoke.cs.toronto.edu> moraes@cs.toronto.edu (Mark Moraes) writes:
>jim@EXPO.LCS.MIT.EDU (Jim Fulton) writes:
>>With System V Release 4, there will be undoubtedly be additional hacking
>>(we're currently planning to use the symbol SVR4 unless there is a new builtin
>>cpp symbol :-).
>
>Please, please, no.  I really wish there were feature based ifdefs
>instead of the clearcut SYSV vs. BSD stuff.

Agreed. There are so many mix-and-match hybrid systems out there, smorgasbord
configuration may be the only way to avoid combinatorial explosion. SYSV.4
promises more (much more) of the same.

Just look at all of the special-casing that is currently done in the SYSV
code blocks. (sgi? stellar? cray? att? -- how about SCO? ISC?) Extrapolate
that out over another half-dozen systems, and you have an unmaintainable mess.

My experience with 386/ix (which is System V3.2 with some Berkeley-ish
enhancements) has been that all of the SYSV/USG/att/STREAMSCONN (and other)
code blocks have to be viewed with suspicion. (That is, they are just as
likely to incorrectly exclude something I have as to provide something I
need.)  And TCPCONN is a misnomer. (It really means something like: SOCKETCONN
or BSDTCPCONN)

Constructing a configuration one-piece-at-a-time would be a headache, but
it probably would be no worse than one-piece-at-a-time deconstruction of
increasingly elusive standard configurations.

If system characteristics/capabilities were all specified independently, that
might even provide a foundation for some amount of real auto-configuration
(ala Larry Wall's config magic).

That will be 2 cents, please.

-------------------
bret@codonics.com
uunet!codonics!bret
Bret Orsburn
-- 
-------------------
bret@codonics.com
uunet!codonics!bret
Bret Orsburn