Randolph Fritz wrote:
I got very busy with other things & didn't have time to work on this.
So here's my last notes--I added an install (note that it doesn't
require a separate environment) and build for meta. What's the status
of the scons scripts for Radiance--has anyone else done work on them?
Here's what I've come up with so far. The file scons_03.tgz
expands into the source tree from the "ray" directory.
I also figured out that we don't need a seperate environment
for installing. That makes things even simpler.
I merged your changes for saving the options into my version.
Apart from that, I went full ahead, and now have a version that
does almost everything I think we need.
Displays the copyright and license text (unless silenced with
"SKIP=1").
Checks for the SGI stereo extension to X11 automatically.
Reads information from a platform specific configuration file as
shipped or a customized version thereof.
Allows to override (some of) the options in the platform files by
command line options.
Stores command line options in a file which will be automatically
consulted from then on (unless you tell it otherwise).
all executables are built in ray/bin[/dev], and all libraries in
ray/src/lib.
builds the standard set of tools and those special tools that
compile on my system with the targets "build" "meta_special",
"px_special", and "util_special"
Installs the standard tools as well as the library files and man
pages (minus the CVS directories) with the "install" targets
(resp. the subtargets "bininstall", "rlibinstall", and
"maninstall"). Special tools are installed with the targets
"meta_special_install", "px_special_install", and
"util_special_install".
I moved most task specific code to a subdirectory "build_utils",
and the platform specific configuration files to "platform".
The latter are found by their name as known by the Python os.name
attribute, such as "platform/<os.name>.cfg". If the exact name
can't be found, then first one and then two characters will be
shaved off the end. This means that os.name == "irix4" will find
the file "irix4.cfg", but eg. "irix5" will instead match the more
generic file "irix.cfg".
If there's a file named "platform/<os.name>_custom.cfg", then
this will be taken instead. This is meant as an easy way to
modify the shipped files while still preserving the original for
reference.
The format of those *.cfg files should be self explanatory.
I kept everything compatible to Python 1.5 for the moment, even
though a few things could be made simple or more elegant with
newer versions.
There are still a few open ends:
There's a mix of tools for fetching options from platform
specific files, from a cache file, and from the command line.
I'm not sure if we already have the best possible combination, or
what the optimal sequence/precedence would be. Most likely,
command line options should be able to override pretty much
everything.
Related to that, I'd like to have a way to bypass all this with a
stored set of options for custom builds or for testing. Ideally,
you could say "scons cfgfile=blah.cfg" and it would just start to
determine the dependencies based on the information in blah.cfg.
This is needed as an equivalent for creating custom rmake files.
I'd also like to reduce the necessity for copying the global
build environment in subdirectories. It currently only happens in
some, but maybe we can eliminate those copies completely. The
reason being that I suspect them to cost us time, but maybe we
should test this theory first.
We need some mechanism to build Version.c from VERSION. This can
be done within SCons, I'll just have to figure out how...
My experiments uncovered several instances of duplicate function
names and file names (including Version.c). If those functions
end up in libraries, then that limits the way those libraries can
be linked later. There's probably some cleanup work to be done
here, but maybe we should address that topic seperately.
There's a number of *.cal and other library files sprinkled
through the source directories (some are duplicates). To make
testing within the build environment possible, those should
probably all be moved to ray/lib[/*].
On Windows, the holodeck display driver files will have to be
changed to the extension *.exe (besides all the other obstacles
to porting the holodeck to Windows). Some of those drivers don't
build on Linux because of a problem in sm_geom.c.
I was unable to figure out why each holodeck display driver is
also linked to an alternative name with an "h" appended to the
original (x11.hdi -> x11h.hdi).
The tifflib is built using its own makefile, which makes it
somewhat platform dependent. If a platform isn't supported by
tifflibs configure script, then the build will currently fail.
I guess we'll have to make a special case for VC on Windows,
but the version of tifflib that we currently use also doesn't
recognize eg. Cygwin. I just checked, and the last stable release
on http://www.remotesensing.org/libtiff/ is 3.5.7, while we're
still using 3.4beta. Are there any fundamental obstacles to
updating our copy of the tifflib?
-schorsch
scons_03.tgz (11.1 KB)
···
--
Georg Mischler -- simulations developer -- schorsch at schorsch com
+schorsch.com+ -- lighting design tools -- http://www.schorsch.com/