IRIX and Performer version nos. for Makefiles and compiler #ifdefs ???

New Message Reply Date view Thread view Subject view Author view

Lew Hitchner (hitchner++at++netcom.com)
Fri, 4 Feb 1994 13:04:32 -0800


Performers,

We currently run different versions of Performer on different IRIS
hosts (on my main workstation I have 1.2 beta installed with 1.0
sitting in separate directories, e.g., /usr/include/Performer_1_0,
etc.). Also, we may soon be using different SGI hosts running
different IRIX versions. I've been trying to find a clean way to
identify what version of IRIX and what version of Performer I am
compiling/linking from and executing from for use in Imakefiles and
compiler #ifdef's. Up until recently I did this by manually editing my
Imakefiles or Makefiles. I was hoping there might be some default
environment variables set, or some global pre-processor define's a la
__sgi, __unix, host_mips, etc.

For the IRIX version I realize I can do something cute with "uname" in
my .cshrc file to set my own env. variable that will tell me what
version of IRIX I'm running, e.g.:

   setenv __IRIX_VERSION `uname -r`

With a little further kludgey processing I can fix up this env.
variable to use in Imakefiles and #define's for C or C++ files (note,
cpp #ifdef's can only use integer values not something like 4.0.5).
But, I'd rather not rely on expecting a login user to have such a
.cshrc kludge. Is there something better?

As far as Performer versions, I've thought of a couple of hacks. One
is to use some #define'd value that's declared in version 1.2 but not
in version 1.0, e.g., PFMP_CULLoDRAW, and then test via #ifdef in
Imakefiles and source files. Alternately, I though of another kludge
such as,

   set pf_vers_date \\`grep Date /usr/include/Performer/pf.h`
   setenv __PF_VERSION `echo $pf_vers_date[2]`

For now I'm requiring myself to explicitly use a -D on my imake command
line that I test for in the Imakefile which creates a compiler -D
define in my Makefile that I can test for in my source code (whew!!!).
This also seems risky and depends on explicit user action rather than
something built in. Is there something better?

        Lew Hitchner
        Xtensory Inc.
        Scotts Valley, CA


New Message Reply Date view Thread view Subject view Author view

This archive was generated by hypermail 2.0b2 on Mon Aug 10 1998 - 17:50:10 PDT

This message has been cleansed for anti-spam protection. Replace '++at++' in any mail addresses with the '@' symbol.