SCons checkin

Hi all,

I just checked the experimental SCons build environment into CVS,
so it will probably be included in the daily HEAD dump tomorrow
for those who like to experiment with it. I decided to do so
after I succeded compiling large parts of Radiance on Windows
with the help of SCons. Francesco reported a problem when trying
the same thing with Cygwin, but I think that's fixed now.

Currently, 86 executables get built without errors on Windows
(although in some areas still with lots of warnings).
The missing parts are as follows:

* mgf2rad trips over duplicate file/function names between
  librt and libmgf.
* The holodeck will require some substantial porting work.
* rtrace and rpict trip over multiple definitions of functions
  named free_os(), as well as over unix specific code in
  raypcalls.c
* Ranimate requires a Windows version of netproc.c.
* Ranimove also has troubles with free_os().
* The X11 dependent stuff is obvious.
* I ignored the tifflib for the moment. Since we seem to be
  migrating to a more current version anyway, are there any
  chances that the rad3R5supp.tar.gz will get updated?
  Or do we need a seperate rad3R6supp.tar.gz?

As one of the next things I'll start resolving name conflicts
throughout the code base, which probably requires some discussion
about what goes where.

-schorsch

···

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

I just checked the experimental SCons build environment into CVS,
[...]

Great! Glad to see that you picked this up.

Randolph, still dealing with the gators

From: Georg Mischler <[email protected]>
Date: Tue Oct 21, 2003 1:07:44 PM US/Pacific

[...]

Currently, 86 executables get built without errors on Windows
(although in some areas still with lots of warnings).
The missing parts are as follows:

* mgf2rad trips over duplicate file/function names between
  librt and libmgf.
* The holodeck will require some substantial porting work.
* rtrace and rpict trip over multiple definitions of functions
  named free_os(), as well as over unix specific code in
  raypcalls.c
* Ranimate requires a Windows version of netproc.c.
* Ranimove also has troubles with free_os().

I rely on being able to override my own library functions in places -- does SCons not support this strategy? If not, then we'll just have to come up with unique functions that perform the same job differently, I suppose. Not a big deal, and better for clarity, anyway.

* The X11 dependent stuff is obvious.
* I ignored the tifflib for the moment. Since we seem to be
  migrating to a more current version anyway, are there any
  chances that the rad3R5supp.tar.gz will get updated?
  Or do we need a seperate rad3R6supp.tar.gz?

I believe the current release of the TIFF library is fully compatible with the 3.5 release. I have uploaded this onto my account on radiance-online.org as ~greg/tiff.tgz if Peter wants to put it in the supplemental materials in place of what's there. I think it would be fine.

-Greg

I rely on being able to override my own library functions in places --
does SCons not support this strategy?

I think it can be made to--were more confused than anything else.

Over the years, you have moved Radiance towards a semi-object-oriented
organization (this is very similar to subclassing) and since you've
been the main person working on the code, never needed to document
this. As people like Georg Mischler and me work on the code, we
stumble into it and get all confused. If I ever have time again
(sigh), I'll try writing some comments that explain these areas.

Once the Grand ANSI Unification project is complete, it might be
interesting to develop an experimental version in some mix of Python
and C++; things like this make me hope it might actually be a
relatively simple project.

Randolph

From: Randolph Fritz <[email protected]>
Date: Wed Oct 22, 2003 1:06:21 PM US/Pacific

I rely on being able to override my own library functions in places --
does SCons not support this strategy?

I think it can be made to--were more confused than anything else.

Over the years, you have moved Radiance towards a semi-object-oriented
organization (this is very similar to subclassing) and since you've
been the main person working on the code, never needed to document
this. As people like Georg Mischler and me work on the code, we
stumble into it and get all confused. If I ever have time again
(sigh), I'll try writing some comments that explain these areas.

I'm really loathe to admit such things, but the free_os() routine has bitten me as well. I wouldn't miss it if we object-deorient it.

-G