* In linking with my standalone programs I will have to link probably
lot's of system stuff which I very likely don't need for my purpose
(see hereafter a specification of the functionality I want).
Furthermore, due this system stuff I might be forced to use Visual C++
from Microsoft, but I want to use the free (and GOOD !) G++ compiler.
* In compiling lot's of unnecessary stuff I am just spending a lot of
compilation time for nothing.
The functionality I only need :
-------------------------------
What I want is the following :
* Have some of my private files (e.g. A.h, A.cc, B.h, B.cc etc...)
containing my private C++ classes and a main program main.cc.
Very likely I will have compiled the A.h, A.cc etc... already and
have them available in a g++ produced static library (e.g. mylib.a).
* In main.cc I want to use the classes from mylib.a and in main.cc
I also want to be able to read a TTree file (or TChain).
With the data obtained from the TTree I want to provide data to my
classes from mylib.a and also fill some histos, graphs etc..
and possible also make some fits to some histos, graphs etc...
* At the end of main.cc I then want to write aout a ROOT file containing
the histos, graphs etc... but also TTrees containing my classes
from mylib.a.
* I want to be able to do :
g++ -s -g0 main.cc -L'some directories' mylib.a root.a
this will produce a file 'a.exe' which is then a standalone program
to be run.
* After running a.exe I will then have a root output file mydata.root
==> Now I consider my batch running completed
To analyse the data in mydata.root I would like to just start a normal
root session (like we have now with the dll's etc...) and do :
root> TFile("mydata.root")
within this root session I would then (hopefully) be able to perform
my analysis, make plots, .ps files etc.....
So as you can see, in my static batch lib I don't need any postscript
functionality nor canvas/pad management or graphics.
These things I only need in the 'data investigation phase' afterwards
in my normal interactive root session.
So as you mentioned, a static ROOT lib for MS-DOS would be ok for me,
however I don't want to use DJGPP but the Cygnus stuff instead since
the Cygnus produced code is much more efficient.
I really would like to ask you guys to see if such a static lib
could be provided (or just introduce a batch selection into the CMZ file,
so that everyone could create his/her own root.a with his/her preferred
compiler). This clearly would greatly enhance running standalone
batchjobs using (parts of) the ROOT system.
In fact this root.a static lib would be some sort of the good old
cern library.
Cheers,
Nick.
*----------------------------------------------------------------------*
Dr. Nick van Eijndhoven Department of Subatomic Physics
email : nick@fys.ruu.nl Utrecht University / NIKHEF
tel. +31-30-2532331 (direct) P.O. Box 80.000
tel. +31-30-2531492 (secr.) NL-3508 TA Utrecht
fax. +31-30-2518689 The Netherlands
WWW : http://www.fys.ruu.nl/~nick Office : Ornstein lab. 172
----------------------------------------------------------------------
tel. +41-22-7679751 (direct) CERN PPE Division / ALICE exp.
tel. +41-22-7675857 (secr.) CH-1211 Geneva 23
fax. +41-22-7679480 Switzerland
CERN beep : 13+7294 Office : B 160 1-012
*----------------------------------------------------------------------*
*** Valery Fine wrote :
>
> Hello Nick,
>
> On 11 Jul 97 at 9:46, you wrote:
> > I want to create a static library
> > root.a which only contains the 'root batch' functionality. As I
> > mentioned to you before, I would like to use g++ to create this lib
> > and also to run my batch jobs with g++. I have taken the root.cmz
> > file and can extract all the source code. However, it is not clear
> > to me which classes etc... I have to compile (and put in this
> > root.a) to have the 'batch only' version. Is there (or could it be
> > introduced) a CMZ selection card 'batch' such that I could say
>
> In fact we didn't separate things like this. When one starts ROOT
> with -b option the only classes disabled is TGXW and its X11/WIN32
> implementations (namely for WIN32 they are all classes started with
> TGWIN32*.
>
> But I think it doesn't worth to separate things. One will gain
> 2%-5% in the size of exe file and nothing for speed. Sverre Jarp at
> CERN had done a "static" version of ROOT with VC++ and told the whole
> ROOT.EXE is roughly 3 Mb. The "pure" batch will be as large as 2.9
> Mb. Is it worth to worry ?
>
> What is a special here. Let's first define what is a "batch"
> version (for you)
>
> 1. Is it version without CINT ? I think no since it is assumed user
> will suppy his macro file to be performed. Otherwise it will be
> not ROOT but a ROOT class-based stand-alone program, like our
> stuff from our "test" subdirectory.
>
> 2. Is it a version without "graphics" and "console" output.
> I think you will agree on "graphics" but "console". The console
> output always exist but could be redirected.
>
> Conclusion: The batch version of ROOT is a version with no graphics
> output (but it is still with Postscript is it ?). This means the only
> thing we can disable is very Graphical view of Canvas, but we still
> need Canvas/Pad to be able to produce postscript output.
>
> Putting all above together I am concluding spending a lot of time
> we will gain 2%-5% of the final ROOT.EXE (root.a) size and it
> doesn't worth does it ?
>
> Likely it makes sense for UNIX version. Under UNIX it would sound
> like version linked with no X11/Motif libraires. But for Windows
> this means "a version linked with no WIN32 API for computer with no
> WIN32 (haa !!!! It will be MS DOS version of ROOT!!! To create MS DOS
> version of ROOT one doesn't need Cygnus staff, DJGPP will be quite
> enough and BEST way").
>
> Probably you realized that under Windows we have to load
> ROOT_Tree.DLL "by hand" (with rootlogon.C). This means that TTRee
> classes are not linked with the main ROOT . The same can be said
> about OpenGL classes. Root_RGL.DLL is loaded (under UNIX - "by
> hand", under Windows - by ROOT itself) when it is required and can be
> done separately.
>
> >
> > cmz> file root
> > cmz> select batch
> > cmz> exe setup
> > cmz> cx *
> > cmz> exit
> >
> > which would then provide me only the *.c and *.C files needed to
> > obtain batch functionality.
>
> Hmm, just idea! Probably you have to look into the TGuiFactory
> class and I think it is only place where the "batch" switch may make
> sense. One has to set it against of WIN32 flag there. Just try.
>
> This way one can create a separate "batch" libraries and to build
> the interactive version one will need another library. So if you
> think it is worth (I mean supporting two different versions of the
> libraries) - just try. Or first try and then tell us whether it is
> worth. I'd like to mention that it is more easy with DLLs. This way
> we need to support two different versions of only small DLL.
>
> With DLL a user will need to create two separate directories and
> put there the versions of that DLL. Then to switch from "batch" to
> "normal" one he needs to change his "path", that's all.
>
>
> >
> > If I get this to work, I obviously can use ROOT/CINT as usual (using
> > the DLL's) to do my program testing and physiscs analysis (plotting,
> > fitting etc...) whereas my heavy batch processing (e.g. producing
> > TTree files for physics analysis afterwards) could then be run with
> > g++ by linking in the root.a lib.
>
> Anyway you will still need ((cygwin32.DLL or MSVCRT.DLL) and NT/95
> kernel) DLLs. (By the way MS supplied the "pure" static libraries, so
> in theory we can create "pure" static version of ROOT with very
> Microsoft SDK).
>
>
> Valery