Re: About ROOT [Was: Re: ROOT as A replacement for gnuplot]
Hi Frederic-Emmanuel,
On Fri, 2005-09-16 at 14:48 +0200, Frederic-Emmanuel PICCA wrote:
>
> Why not using scons ?
Quite frankly, it's not good enough.
First off, SCons reminds me of Imake (used by CERNLIB amoung others), in
that it uses functions to declare various stuff. That initially made me
weary, as Imake is a pain in the behind.
Reading further into the manual, I was glad to see that it actually had
and Autoconf-like feature for checking for availability of libraries,
headers, and so on. And more importantly, it seemed that it actually
does this the right way. That is, it doesn't merely check for the
existence of the library and/or header file - it actually runs the
compiler/linker to see if it can find the library/header, and whether it
can be used - just as Autoconf does.
The platform independence aspect seems to be dealt with via the conept
of environments, predefined by SCons. I have no idea that works. What
most systems does (and SCons seems to do), is to have some sort of
environment definition that has a one-to-one (sometimes many-to-one, or
one-to-many) mapping from target OS (as reported by `uname`). In
general, that's a bad idea. It's much better to test what the system is
actually like: Is it 64bit? Is it big or little endian? Does the
compiler understand `-fPIC'? What kind of output does the compiler
proper produce - .o or .obj files? and so on. The other approach fails
miserably if `unexpected' cases, like Linux on a 64bit little endian
machine, using the Intel C/C++ compiler rather than GCC, and so on.
In other words, it's much better (read: portable) to test things, rather
than rely on predefined environments.
The build-cache idea is nice, however, it's not a major thing. Similar
things can be done using symlinks, or what not.
I'm not overly impressed by the installation techniques used in SCons.
It seems far too convoluted for some reasonably simple things.
The idea of using MD5 checksums to detect updated sources is nice, but I
doubt it has great merits over timestamps.
Finally, and my most important hick-up, is that it's based on Python.
Not that I don't like Python (I haven't really used it, so I can't say),
it has more to do with the fact, that SCons introduces a non-standard
tool as a build requirement.
The good thing about using Make or make-based build tools (like
Autotools), is that it only uses standardised tools. By `standardised'
tools I mean tools that are specified in standards like POSIX, SUSV3, or
similar. That creates less of a burden for the end user _and_ the
developer. Also, using standardised tools like Make, SH, and similar,
there's a good chance that any version of those tools will suffice.
With Python, Perl, Scheme, Lisp, and so on, you may get into the
situation where you require a specific version of these tools for the
build system to work.
Also, using standardised tools, the end-user has a good chance of
knowing how to deal with it.
So to summerise: I think SCons has done some good things, and it's
definitely not the worst build system I've seen. However, I think
using Python is a bad idea, and I think some of the decisions they made
with regards to platform independence are wrong. Finally, the fact that
it's not standardised makes in very unattractive.
Yours,
--
___ | Christian Holm Christensen
|_| | -------------------------------------------------------------
| | Address: Sankt Hansgade 23, 1. th. Phone: (+45) 35 35 96 91
_| DK-2200 Copenhagen N Cell: (+45) 24 61 85 91
_| Denmark Office: (+45) 353 25 404
____| Email: cholm@nbi.dk Web: www.nbi.dk/~cholm
| |
Reply to: