Hi all,
I think it's about time I say a few words on ROOT, and ROOT and Debian.
On Thu, 2005-09-15 at 17:04 -0400, Brett Viren wrote:
> Thomas Walter <t.walter@nefkom.net> writes:
>
> > I had a quick look at the sources. Really large.
It is. It represents the development effort of some 20-30 people over
the past 10 years or so. Many contributors have submitted `plugins'
needed by their specific application, and the ROOT team has mostly
accepted these. The idea is that ROOT is an open system with a couple
of benevolent dictators (Rene Brun and Fons Rademarkers) at the top.
The general policy to accept contributions seems to be `if it doesn't
anything else, and follows guidelines, and might be useful to some, it's
accepted.' This policy has been instrumental in the wide-spread
adoption of ROOT.
> Indeed.
>
> > From my point of view, it would profit if the build system will be
> > converted to use
> > autoheader, autoconf,automake,configure, libtool
Please lobby the ROOT mailing list to get this going :-)
The build system of ROOT is horrible - I should know, I helped make it
initially. Back when we did the build system, Autotools was really an
option, for a verity of reasons. The foremost was (and still is), that
Autotools (Libtool in particular) doesn't support MSVC well. Secondly,
at that time, it was possible to make a non-recursive build system, and
thirdly, the upstream developers wasn't that familiar with Autotools and
it sort of looked too complicated for their taste.
Now, as you all probably know, the third reason is basically wrong. The
current build system of ROOT is far more complicated than it would ever
be with Autotools. I think I've managed to convince at least one
upstream developer of this.
The second reason has since been obsoleted by developments in Automake.
The first reason, that MSVC (Microshit Visual C--) isn't supported by
Libtool, still remains. People on this list might say why care about
MSVC - we've got Cygwin. However, the fact of the matter is, that
there's a large number of ROOT users out there that does use MSVC, and
have developed applications with MSVC that uses ROOT. These cannot
always easily be ported to Cygwin. Hence, it's crucial that the build
system support MSVC. An option could be to have separate build systems
- one using MSVC's build system, and Autotools for the rest. However,
that solution isn't acceptable to the upstream developers. The build
system need to work on _all_ supported platforms.
Now, what is needed for Libtool to better support MSVC? Well, first of
all, it needs to know that there's a compiler called `cl.exe', with
linkers `lib.exe' and `link.exe', and it needs to know when to call
what. Secondly, Libtool needs to know the proper switches for these
applications. Thirdly, Libtool needs to know how to make DLL
(Dynamically Loadable Libraries - or shared libraries in Unix lingo),
_as_well_as_ binding libraries (.lib files).
Of course, one can try to trick Libtool to think that it knows what to
do. Essentially it's a wrapper script that takes care of translating
GCC-like options to MSVC options. (I've attached a shot at such a
script - please provide feed back if you can).
Oh, I almost forgot. There's an additional reason why Autotools may not
be adopted by ROOT. The traditional way of installing ROOT is to build
everything in the source directory, set the environment variable ROOTSYS
to point to that directory, and include `$ROOTSYS/bin' in PATH, and `
$ROOTSYS/lib' in `LD_LIBRARY_PATH'. Many users rely on this behaviour,
ugly as it might be (in fact, much of my contribution to the build
system was to make sure you could install and run ROOT from system
directories like `/usr/bin').
> This might happen if someone contributes it, but best check if
> upstream is accepting first before doing a lot of work. I doubt
> upstream will do this work themselves since the existing "configure"
> script mostly works.
`Mostly' being the operative word here.
I think that upstream does know that Autotools would provide a better
build system, but they are hesitant for the reasons outlined above.
Secondly, upstream will most probably not do that work themselves, but
rather rely on some one else doing it. I did a small test once, as a
proof-of-principle, and upstream wasn't entirely dismissive.
That said, there may be things in the future that will change all this.
Recent developments in CINT (which is needed by ROOT) indicates that
they (CINT) will switch to Autotools. If that happens, then ROOT should
build-depend on CINT, and would then benefit even more from switching to
Autotools.
Some one suggested that the plugins should really live in it's own
source tree, and I couldn't agree more. However, as things are now,
that's really not an option for ROOT. The main thing being, that the
plugins depend on being in the main source tree. Ideally, upstream
would make a `core' ROOT source tree, and have plugins live in their own
CVS repository, and build-depend on the ROOT core. I've suggested this
to upstream, and even though they are not entirely dismissive, they seem
not to be too eager either. In fact, if they did that, upstream would
get rid of a lot of problems that they currently have. Ah well. Lobby
for this on roottalk@root.cern.ch if you please.
> Do I understand the source correct,
> > ROOT comes with a copy of 'cint'.
> > Is this necessary or can it use an existing 'cint'?
>
> Yes, it is absolutely (and unfortunately) central.
>
Now, a few words on CINT. ROOT cannot use `prestine' CINT! There are
hooks in the ROOT version of CINT that is need by ROOT, but isn't
present in the normal CINT. That said, the CINT developers are working
closely with the ROOT developers. In act, ROOT has a much larger user
base than CINT.
> CINT (C/C++ INTerpreter) provides the interactive shell, scripting
> language as well as the means to introduce reflection to C++ (although
> this last job will be done by another tool in the near future).
CINT, as it is now, is an ugly piece of hack. However, as Brett says,
in the not too far away future, CINT will change a lot, using more
modern approaches for parsing C/C++ and introspection and reflection of
C/C++. In the ROOT source tree, one can see some of these initiatives
in the directory `reflex' as well as the source files `cint/src/bc_*'.
The up-coming ROOT 2005 conference will probably reveal more.
I wouldn't, as Brett does, say it's unfortunate that ROOT uses CINT.
CINT is what gives ROOT the interactive C++ interpreter which is very
useful what ROOT's application domain. What is unfortunate is that CINT
is an ugly piece of code.
The package `root-cint' is there in the case that CINT will become it's
own standalone package once more. If, as I said previously, CINT
switches to Autotools in the not so far away future, I think that would
be real opportunity. Also, in that case ROOT would probably be able to
use pristine CINT.
Please, if you have more questions, bugs, flames, etc. on the ROOT
packages for Debian, do not hesitate to write. I'll try to answer the
best that I can.
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
| |
Attachment:
cl
Description: application/shellscript