Compiling Radiance with Scons under windows

Hi,

after a long time of absence I'm very happy to see Radiance is still alive with a lot of people pushing Radiance forward together with Greg himself, implementing things like photons maps, meshes etc. :slight_smile:
Today I tried to compile Radiance under windows. I installed mingw and msys to have the basic unix-like tools, a shell, gcc and such things (a similar thing as cygwin). But I dön't know, what kind of shell msys uses, the makeall-script failed with things like "foreach". So I tried the Python-way and installed Scons. Scons detected a win32-system, so I put my settings for gcc into the win32.cfg-file. The first call of gcc gives me the following error:

gcc -O2 -Dfreebsd -DHDSUF=.exe -Isrc\common -c -o src\meta\meta2tga.o src\meta\meta2tga.c
In file included from f:/MinGW/include/process.h:36,
                 from src/common/rtprocess.h:16,
                 from src/meta/meta2tga.c:10:
f:/MinGW/include/sys/types.h:90: conflicting types for `pid_t'
src/common/rtprocess.h:15: previous declaration of `pid_t'

Scons sets the _WIN32 flag, in rtprocess.h pid_t is declared as DWORD:

#ifdef _WIN32
  #include <windows.h> /* DWORD etc. */
  #include <stdio.h>
  typedef DWORD pid_t;

In types.h pid_t is declared as int:

ifndef _PID_T_
#define _PID_T_
typedef int _pid_t;

#ifndef _NO_OLDNAMES
typedef _pid_t pid_t;
#endif
#endif /* Not _PID_T_ */

How can I tell Scons my system is not really win32, rather a *nix-like thing to prevent such conflicts?
Or is there a free one true win32-compiler I can use together with Scons?

Tschau,
  Sabine

Sabine Wolf wrote:

Hi,

after a long time of absence

Welcome back!

Scons detected
a win32-system, so I put my settings for gcc into the win32.cfg-file.

If you change the default settings in a platform config
file, it's better to make a copy as platform/win32_custom.cfg.
If such a *.custom.cfg file exists, then our SCons script will
use that instead of the original.

I'm assuming that you want to create real Win32 binaries, which
will use the native OS APIs. If this happens to work equally well
as with the VC that I'm using, then we should probably try to
detect when SCons is about to run with mingw, and provide an
extra config file for that. If you're trying to build against
the posix APIs that may come with mingw's, then you probably
better copy the cygwin.cfg file for your custom settings.

The first call of gcc gives me the following error:

f:/MinGW/include/sys/types.h:90: conflicting types for `pid_t'
src/common/rtprocess.h:15: previous declaration of `pid_t'

The code involved here made an assumption that doesn't happen to
be correct when you compile with mingw. It assumed that a build
system would *either* know about the posix pid_t type, *or* about
Windows native process IDs. On Windows, I simply hijacked the
type name pid_t to mean the other one. Since mingw apparently
exposes both APIs next to each other, this creates a conflict
there.

I now changed src/common/rtprocess.h to define its own platform
independent type name, which is cleaner and avoids any confusion.
The fix is in CVS, so you can fech the file through the web, and
it will also be in the HEAD dump tomorrow. If you want to fiddle
with it yourself, below's the context diff. There are only a few
lines that have changed.

-schorsch

RCS file: /cvs/radiance/ray/src/common/rtprocess.h,v
retrieving revision 3.9
diff -c -r3.9 rtprocess.h
*** rtprocess.h 14 Nov 2003 17:22:06 -0000 3.9
--- rtprocess.h 28 Jan 2004 12:40:21 -0000

···

***************
*** 12,18 ****
  #ifdef _WIN32
    #include <windows.h> /* DWORD etc. */
    #include <stdio.h>
! typedef DWORD pid_t;
    #include <process.h> /* getpid() and others */
    #define nice(inc) win_nice(inc)

--- 12,18 ----
  #ifdef _WIN32
    #include <windows.h> /* DWORD etc. */
    #include <stdio.h>
! typedef DWORD RT_PID;
    #include <process.h> /* getpid() and others */
    #define nice(inc) win_nice(inc)

***************
*** 30,35 ****
--- 30,37 ----
  #else
    #include <stdio.h>
    #include <sys/param.h>
+ #include <sys/types.h>
+ typedef pid_t RT_PID;
  #endif

  #include "paths.h"
***************
*** 43,50 ****

     This means that we shouldn't rely on PIDs and file descriptors
     being the same type, so we have to describe processes with a struct,
! instead of the original int[3]. To keep things simple, we typedef
! the posix pid_t on those systems that don't have it already.
  */

--- 45,52 ----

     This means that we shouldn't rely on PIDs and file descriptors
     being the same type, so we have to describe processes with a struct,
! instead of the original int[3]. For that purpose, we typedef a
! platform independent RT_PID.
  */

***************
*** 64,70 ****
        int r; /* read handle */
        int w; /* write handle */
        int running; /* doing something */
! pid_t pid; /* process ID */
  } SUBPROC;

  #define SP_INACTIVE {-1,-1,0,0} /* for static initializations */
--- 66,72 ----
        int r; /* read handle */
        int w; /* write handle */
        int running; /* doing something */
! RT_PID pid; /* process ID */
  } SUBPROC;

  #define SP_INACTIVE {-1,-1,0,0} /* for static initializations */

--
Georg Mischler -- simulations developer -- schorsch at schorsch com
+schorsch.com+ -- lighting design tools -- http://www.schorsch.com/