From xemacs-m  Sat Jan 11 02:24:48 1997
Received: from venus.Sun.COM (venus.Sun.COM [192.9.25.5])
          by xemacs.org (8.8.4/8.8.4) with SMTP
	  id CAA26924 for <xemacs-beta@xemacs.org>; Sat, 11 Jan 1997 02:24:48 -0600 (CST)
Received: from Eng.Sun.COM ([129.146.1.25]) by venus.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id AAA04656 for <xemacs-beta@xemacs.org>; Sat, 11 Jan 1997 00:24:17 -0800
Received: from kindra.eng.sun.com by Eng.Sun.COM (SMI-8.6/SMI-5.3)
	id AAA26279; Sat, 11 Jan 1997 00:24:16 -0800
Received: from xemacs.eng.sun.com by kindra.eng.sun.com (SMI-8.6/SMI-SVR4)
	id AAA11286; Sat, 11 Jan 1997 00:24:15 -0800
Received: by xemacs.eng.sun.com (SMI-8.6/SMI-SVR4)
	id AAA29475; Sat, 11 Jan 1997 00:24:13 -0800
Date: Sat, 11 Jan 1997 00:24:13 -0800
Message-Id: <199701110824.AAA29475@xemacs.eng.sun.com>
From: Martin Buchholz <mrb@Eng.Sun.COM>
To: XEmacs Beta Test <xemacs-beta@xemacs.org>
Subject: SGI's and cpp
Reply-To: Martin Buchholz <mrb@Eng.Sun.COM>
Mime-Version: 1.0 (generated by tm-edit 7.100)
Content-Type: text/plain; charset=US-ASCII

To SGI users: please rescue your platform as follows:

OK, so SGI cpp doesn't grok #elif.  but cc certainly does, since the C
code is liberally peppered with them.  So it is likely that some way
to invoke cc will give you a valid cpp that understands #elif,
hopefully without introducing new problems related to gratuitous
blanks being inserted by the ANSI preprocessing.

configure has lots of system-specific tests to decide on the right way
to invoke cc to get ANSI pre-processing.  For example, for HP's, you
see 

    NON_GNU_CPP="cc -Aa -E"

in configure.

So if cc is your C compiler, try:

export CPP='cc -E'
configure
make

If that doesn't work, play around with other options to cc.

If you're sure SGI's cannot be gotten to work this way, we simply
won't use #elif in the code.  These are only used in
src/Makefile.in.in 

In this case, please submit a patch against src/Makefile.in.in that
changes all the #elif's to #else's, and inserts the #endif's *carefully*
in the appropriate spot in the file.  Oh, and test that the resultant
code builds on SGI's.

BTW, I notice in configure the section for SGI's is as follows:

  ## Silicon Graphics machines
  ## Iris 2500 and Iris 2500 Turbo (aka the Iris 3030)
  m68*-sgi-iris3.5* ) machine=irist opsys=iris3-5 ;;
  m68*-sgi-iris3.6* | m68*-sgi-iris*) machine=irist opsys=iris3-6 ;;
  ## Iris 4D
  mips-sgi-irix3.*      ) machine=iris4d opsys=irix3-3 ;;
  mips-sgi-irix4.*      ) machine=iris4d opsys=irix4-0 ;;
  mips-sgi-irix6*       ) machine=iris4d opsys=irix6-0  NON_GNU_CPP=/lib/cpp ;;
  mips-sgi-irix5.[3-9]* ) machine=iris4d opsys=irix5-3 ;;
  mips-sgi-irix5.2*     ) machine=iris4d opsys=irix5-2 ;;
  mips-sgi-irix5.1*     ) machine=iris4d opsys=irix5-1 ;;
  mips-sgi-irix*        ) machine=iris4d opsys=irix5-0 ;;

Where did the setting for NON_GNU_CPP just for irix6 come from??
Could simply removing that assignment for NON_GNU_CPP above fix the
problem, by getting configure to use cc -E ?

SGI'ers, please investigate.

Martin

