SCons [was: Radiance quality assurance...]

radiance-dev
1

Peter Apian-Bennewitz wrote:

Randolph Fritz wrote:

In terms of Scons* (which I haven't actually tried yet),* well, is
requiring Python 1.5.2 for build (not execution) such a terrible
thing? 1.5.2 is pretty old now, and it runs on every platform
Radiance runs on, as far as I know. It is even preinstalled on Mac OS
X and most Linuxen. Greg?

Wouldn't it be good if you gain some solid experience with something new
first, /before/ going to lengthly theoretical arguments ?
P.

If that was a good counter-argument, then nobody would ever try
anything new, or even think about it... This list is for thinking
collectively about the Radiance development process, I'm not
quite sure why you dislike this particular thought so much.

SCons has a proven track report, and it is being used in other
projects with great success. And nobody suggested to throw out
the makefiles now, and to think about a way to replace them
afterwards. If someone finds the time to setup the necessary
SCons environment, both methods can coexist without the slightest
problems until we have established which is favourized by the
people out there trying to compile Radiance.

Erwin Rol wrote:

It always seems that writing yer own keeps things simpler in the
beginning until you project grows and than you hit the same problems
other ppl already had and solved.

You make a few good points there (even though you don't seem to
be fully aware of the specific experience and skill sets of the
developers involved). Although you didn't say so explicitly, you
seem to want us to use autoconf and friends. But in line with
your own arguments: Making things simpler is one of the most
interesting goals here.

While autoconf is very powerful and solves lots of problems, it
isn't exactly simple, and brings quite a few problems of its own.
Most noteably, it is itself based on inadequate and platform
(unix) dependent tools, a limitation it shares with the current
makeall script in Radiance (and parts of the Radiance codebase).

Autoconf is generally used for several distinct tasks:

a) establish the toolchain
     (figure out which compiler and other tools to use)
b) analyze the system environment
     (find the necessary system headers, and check whether they
     contain specific declarations)
c) build the software
d) install the software

The biggest and most convoluted part of that is b). Radiance has
very few platform dependencies, the idea actually is to reduce
them to none between unix systems. So in effect, we don't need b).

The simplest part is d), so we don't need any premade tools for
that one either.

Which leaves us with a) and c). SCons offers a much simpler and
yet more powerful solution for both, and it does so on platforms
that autoconf will never know about.

-schorsch

···

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

2

Erwin Rol wrote:
>
> It always seems that writing yer own keeps things simpler in the
> beginning until you project grows and than you hit the same problems
> other ppl already had and solved.

You make a few good points there (even though you don't seem to
be fully aware of the specific experience and skill sets of the
developers involved).

I wanted in no way suggest that radiance developers only can write
renderer/math software.

Although you didn't say so explicitly, you
seem to want us to use autoconf and friends.

I used automake/autoconf for other things, and i don't know SCons, so
thats why i mentioned autoconf.

But in line with
your own arguments: Making things simpler is one of the most
interesting goals here.

While autoconf is very powerful and solves lots of problems, it
isn't exactly simple, and brings quite a few problems of its own.

Simple depends on yer point of view, for simple programs autoconf
scripts can be very simple, for complex programs ( complex as in complex
dependencies on the system , not complex as in complex math in the code)
the scripts get more complex.

Most noteably, it is itself based on inadequate and platform
(unix) dependent tools, a limitation it shares with the current
makeall script in Radiance (and parts of the Radiance codebase).

True. Al tough the radiance scripts limitations are worse, since it
can't find out the type of Unix on its own.

Autoconf is generally used for several distinct tasks:

a) establish the toolchain
     (figure out which compiler and other tools to use)
b) analyze the system environment
     (find the necessary system headers, and check whether they
     contain specific declarations)
c) build the software
d) install the software

The biggest and most convoluted part of that is b). Radiance has
very few platform dependencies, the idea actually is to reduce
them to none between unix systems. So in effect, we don't need b).

The simplest part is d), so we don't need any premade tools for
that one either.

Which leaves us with a) and c). SCons offers a much simpler and
yet more powerful solution for both, and it does so on platforms
that autoconf will never know about.

How well does SCons for example deal with building shared libraries ?
(whcih is part of point c ).

-schorsch

But anyway, i would vote for any more sophisticate build system than
hand written scripts, not just autoconf.

- Erwin

···

On Sun, 2003-08-03 at 14:08, Georg Mischler wrote:

3

If no-one is dead-set against it (and no-one has written to say they
are), I'm going to give it a try, then.

Randolph

···

On Sun, Aug 03, 2003 at 08:08:00AM -0400, Georg Mischler wrote:

SCons has a proven track report, and it is being used in other
projects with great success. And nobody suggested to throw out
the makefiles now, and to think about a way to replace them
afterwards. If someone finds the time to setup the necessary
SCons environment, both methods can coexist without the slightest
problems until we have established which is favourized by the
people out there trying to compile Radiance.

4

I have been silent during this discussion not from lack of interest or relevant comments, but because I was off at SIGGRAPH in San Diego last week and unable to respond to (or comfortably read) e-mail.

In general, I am opposed to "enhancements" to the distribution that require people to compile other packages, unless they are freely available and supported on all platforms and provide a substantial benefit to a majority of people (or developers for the build system). In the case of SCons, which I know nothing about, it sounds like it is free and depends on Python, which is preinstalled on many systems and probably easy to install on most others. This leaves only the second requirement -- that SCons provide such an improvement to the system that it is worth the added effort....

Schorsch has suggested (more than once) that the current C-shell scripts that are part of Radiance should be rewritten, either as C programs or Python/Perl scripts. I tend to agree, if only because these languages are better supported on non-Unix systems than C-shell. If they are rewritten as Python scripts, then SCons would be no added effort over the default system. If it would also provide some benefit in maintenance or ease of compilation, then I would favor it.

These are the questions I have about it:

1) Is Python available precompiled or easily built on all systems we support?

2) Is SCons sufficiently stable that we don't have to be updating our build input to keep compatibility with different SCons releases? This can be a nightmare for deployment.

3) What benefit does SCons offer over our current script-builds-rmake system, which is quite simple when compared with almost any other build system I've seen? The rmake command is intelligible, the Rmakefile's are intelligible, and even the makeall command is pretty easy to follow. Take a quick peek at any of the files in a typical autoconf build system for comparison. I'd like to see what SCons expects as input.

In the following e-mail, I will address some of the more specific compile issues brought up last week.

-Greg

5

A few more notes on this.

These are the questions I have about it:

1) Is Python available precompiled or easily built on all systems we
support?

Yes--installed in Mac OS X since 10.2 at least, usually automatically
installed on Linux and available in all the standard distributions;
precompiled on Windows, but you do have to download it. The Python
builder is autoconf, which will try to build on any *nix version. I
can find reports of Python on IRIX, POSIX, and BSD and support seems
to be good.

Python is at version 2.3; scons only requires Python 1.5.2, which is
relatively old and common.

2) Is SCons sufficiently stable that we don't have to be updating our
build input to keep compatibility with different SCons releases? This
can be a nightmare for deployment.

To judge by their web site the scons developers are aware of these
issues and addressing them. They write, "We ensure that today's
functionality isn't broken by tomorrow's release through rigorous use
of a development methodology that adds incrementally to an extensive
set of regression tests: non-comment lines of test code outnumber
lines of production code by more than 2.5 to 1." Serious QA
commitment there.

Randolph

Web sites:
  http://scons.sourceforge.net/
  http://www.python.org

···

On Mon, Aug 04, 2003 at 11:23:32AM -0700, Greg Ward wrote: