Re: Why I am forced to abandon Root

Hi Tom,

Neither the IO library nor the TTree library depends on the histogram package or the X windows.

 > The existence of the non-Root "RIO" package indicates I am not alone in this.

'RIO' was created many years ago and we have addressed the modularity issues since.

 > I understand the reasons for that, but this design is preventing me from compiling Root
 > because it inherently brings in the image and X-Windows code.

It should not bring X windows if you are not using it.

 > At base, this is caused by the fact that TObject::Draw() exists, and is implemented for TFile, TDirectory, and TNtuple.

The connection between the implementation of Draw and the actual display is done via
an abstract interface. The X11 code is pulled in via a plugin and should not be needed
unless you need it (and you may have to tell ROOT to be a batch mode rather than the
default graphical mode).

Could you please send to rootdev the actual example that you are trying to reduce
(note that I am aware of linking problem of the static libraries on macos that we do indeed want to fix).

 > In closing, I'll point out that in casual conversations at Fermilab I have been told by several people "
 > don't use Root" (in a computationally intensive context), for just this reason.

Please don't hesitate to stop by my office (and/or direct the appropriate person) to discuss this.
ROOT I/O is definitively usable in most environment and were it is done we ought to address the issues.

Cheers,
Philippe.

Tom Roberts wrote:
> I have been using Root for 3-4 years, and have been reasonably happy
> with it. But I have long been frustrated with build issues, that have
> now culminated in my complete inability to build Root on a
> supercomputer at NERSC. The underlying problem is:
>
> LACK OF MODULARITY
>
> Note that the only Root classes that my code uses are: TNtuple, TFile,
> TDirectory, and the only Root functionality is to read and write
> TNtuple-s to and from TFile-s.
>
> Performing such basic Root I/O brings in an INCREDIBLE amount of Root
> code. I understand that the desire to read arbitrary objects from Root
> files beings in Cint and related dictionary code; I could live with
> that. But this also brings in the image libraries and X-Windows -- I
> CANNOT live with that, for the simple reason that the supercomputer
> does not support shared objects or X-windows on its compute nodes.
>
> At base, this is caused by the fact that TObject::Draw() exists, and
> is implemented for TFile, TDirectory, and TNtuple. I understand the
> reasons for that, but this design is preventing me from compiling Root
> because it inherently brings in the image and X-Windows code.
>
> So I am forced to use a file format other than Root. I could use ASCII
> files, but for large problems that is inefficient. I am considering
> both SDDS and HDF5. Suggestions?
>
> Another possibility would be to make Root usable for such
> applications. I believe this could be done with only modest effort:
> A) re-factoring TFile, TDirectory, TNtuple, etc. so they each have
> an "IO-Only" base class that has an empty Draw(); the
> current class derives from this new base class and implements
> Draw(). There might be other functions from TObject that need
> such treatment, and there might be other classes that would
> benefit from such re-factoring (e.g. TH*, ...); the idea is to
> avoid bringing in functionality unrelated to I/O, and most
> especially other libraries -- IMHO success would be if the
> IO-Only build of Root requires no external libraries other
> than system libs.
> A') Instead of that re-factoring, just use a "#ifdef IOOnly"
> to implement a dummy Draw() (etc.) in appropriate classes;
> use the build system to omit all non-I/O stuff.
> B) extending the build system so an "IO-Only" version could be
> built on a system without image libraries or X-Windows.
> C) Documenting and testing the above.
>
> In closing, I'll point out that in casual conversations at Fermilab I
> have been told by several people "don't use Root" (in a
> computationally intensive context), for just this reason. Perhaps it
> is in the interest of the general Root community to solve this
> problem. A complete re-organization is clearly neither possible nor
> desirable, but the ability to build and link root for JUST I/O would
> be most welcome. The existence of the non-Root "RIO" package indicates
> I am not alone in this.
>
>
> Tom Roberts
>
Received on Thu Sep 03 2009 - 21:19:21 CEST