Re: Why I am forced to abandon Root

Hi Tom,

Philippe already answered most of your points. Just to add/insist on Philippe's points

   -The fact that TFile has a Draw method does not imply that you load the X windows system. This shows that either

   you do not understand the basics of object oriented programming or you have been fooled by the name "Draw" without

   doing a real investigation.
  -you have tried to use a totally unreasonable old-fashioned approach with archive libraries and static linking. Whatever you do in the future with this approach will fail, but it may explain why you had the impression that the X window system was systematically loaded. Use the shared libraries to see the modularity of the system.

Good luck with your future system.

Rene Brun

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 - 22:50:18 CEST