mikep@sco.COM (Mike Patnode) (04/11/90)
Shouldn't line number 7 in X11/Xlibos.h be
#ifdef SYSV
/*
* UNIX System V Release 3.2
*/
#include <sys/stropts.h>
.
.
.
instead of
#ifdef att
/*
* UNIX System V Release 3.2
*/
#include <sys/stropts.h>
.
.
.
Or did I miss a line in my speed reading of the release notes? Sure,
it's not that big a deal, until you realize you have to do another,
make { makefiles, depend, clean } again.
--
Mike Patnode The Santa Cruz Operation
SCO Software Engineer 400 Encinal Street
{ucscc,uunet}!sco!mikep mikep@sco.COM P.O. Box 1900
(408) 458-1422 Santa Cruz, CA 95061jim@EXPO.LCS.MIT.EDU (Jim Fulton) (04/11/90)
Shouldn't line number 7 in X11/Xlibos.h be
#ifdef SYSV
instead of
#ifdef att
Possibly, but not necessarily. There are 4 symbols used in R4 for System
V-ish things:
SYSV SVR2 systems
USG SVR3 systems
att AT&T 6386 running V.3.2 ("pure UNIX"?)
STREAMSCONN tli connection
The block in question probably has more to do with STREAMSCONN than USG (SYSV
is for earlier derivatives), although our System V expertise is limited to
HP-UX, A/UX, UNICOS, and System V Release 3.2 on the 6386. Suggestions from
people with more experience with SVR3 and and later are always welcome.
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 :-).moraes@cs.toronto.edu (Mark Moraes) (04/12/90)
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. Soon we're going to have SVR4, 4.4BSD, Mach and OSF/1 out there; plus we're going to have different vendors mixing and matching features from all of them. With liberal doses of Posix compatibility thrown in. And other standards people haven't invented yet, to misquote the SCO ads. Mark. -- Sometimes, it's deja vu all over again.
mikep@sco.COM (Mike Patnode) (04/13/90)
In article <9004111514.AA11945@kanga.lcs.mit.edu> jim@EXPO.LCS.MIT.EDU (Jim Fulton) writes:
+>
+> Shouldn't line number 7 in X11/Xlibos.h be
+>
+> #ifdef SYSV
+>
+> instead of
+>
+> #ifdef att
+>The block in question probably has more to do with STREAMSCONN than USG (SYSV
Agreed. Some SVR3 derivatives may not want to use streams.
+>Possibly, but not necessarily. There are 4 symbols used in R4 for System
+>V-ish things:
+>
+> SYSV SVR2 systems
+>
+> USG SVR3 systems
+>
+> att AT&T 6386 running V.3.2 ("pure UNIX"?)
The #ifdef att stuff sort of sneaks up on you. (It's also prevelent in
xterm) The SYSV and USG stuff is well document elsewhere (Release Notes
, imakemdep.h, etc).
It seems to me that all the #ifdef att's should be #ifdef USG's since I
can't imagine the case where you would see:
#if defined(att) && !defined(USG)
Any decenting opinions?
--
Mike Patnode The Santa Cruz Operation
SCO Software Engineer 400 Encinal Street
{ucscc,uunet}!sco!mikep mikep@sco.COM P.O. Box 1900
(408) 458-1422 Santa Cruz, CA 95061bret@codonics.COM (Bret Orsburn) (04/13/90)
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