Erwin Rol wrote:
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.
As long as configure is only used to determine the right compiler
options, I'll agree with you without hesitation (at least on
unix). As soon as feature selection comes into the picture,
autoconf mandates that certain cpp macros be used in the code,
which causes my complexity meter to jump by several notches.
I'd still like to eventually get away from shell script based
solutions completely. In my view, shell scripts are an obsolete
heritage from the time when all "real" programming languages
required complicated procedures to build programs. Nowadays we
have Python (Perl, Tcl, Ruby, etc.), which bridge the gap between
language functionality and ease of use in a much more effective
and platform independent way.
There's no rational justification for writing any *new* shell
scripts larger than 5 lines in 2003. Unfortunately, maintaining
existing scripts is a different story.
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. Altough the radiance scripts limitations are worse, since it
can't find out the type of Unix on its own.
I don't consider this a big problem (the person doing the compile
should know, right?), even if an automatic detection would be
more elegant.
The serious problems are with scripts like falsecolor etc.
There are C replacements available from Radiance 3.3 (as in
DesktopRadiance and Rayfront) for some of them, but those will
have to be fixed to work reliably (eg. to accept file names with
spaces, etc.). Maybe I should just check them into CVS, so that
anyone feeling adventurous enough can start playing around with
them.
How well does SCons for example deal with building shared libraries ?
(whcih is part of point c ).
That's an integral part of the basic functionality. SCons isn't a
generic tool like make, it contains a lot of builtin intelligence
about standard build procedures. Check the manpage for a very
cursory overview of the target types and tools directly supported:
http://www.scons.org/doc/HTML/scons-man.html
Other target types and tools can be easily added (at least by a
somewhat experienced Python programmer).
But anyway, i would vote for any more sophisticate build system than
hand written scripts, not just autoconf.
Ultimately, we'll have to convince Greg about any alternatives.
In the mean time, I'd have no problem with people experimenting
with whatever tools they know and like. I assume we have several
people with autoconf experience reading here, and we already have
two who expressed interest in SCons. Competition furthers
innovation, doesn't it? The best way to decide about the right
tool is to compare contributed solutions side by side.
Gentlemen, start your engines!
-schorsch
···
--
Georg Mischler -- simulations developer -- schorsch at schorsch com
+schorsch.com+ -- lighting design tools -- http://www.schorsch.com/