> Thanks for your quick answer concerning my effort of getting a
> static root.a lib providing batch functionality. It seems to me that
> you misunderstood some points. The size of the root.a is not at all
> my concern, but the fact that if I compile everything the
> disadvantages are :
>
> * 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).
That's partly right unless one applies DLL approach.
> 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.
As soon as OS of your choice is either Windows 95 or Window NT or
Window CE you had been forced yourself to use Microsoft stuff
ANYWAY (with Microsoft, Symantec, Borland or GNUWIN32 compilers).
The only advantage of the GNU stuff (we are not discussing price)
comes in when one wishes to port UNIX code to Windows and doesn't
want to read any WIN32 book. This way GNU-WIN32 stuff from Cygnus
offers some benefits since it wraps/hides the WIN32 API via
GNU-WIN LIBC library and EMULATEs/implements some UNIX functions
missed under WIN32 subsystem. So the user doesn't need to learn
WIN32 API himself.
This means with GNU-WIN32 one still needs ALL Microsoft stuff (I
mean DLLs) + Cygnus ones to wrap it TOO.
>
> * In compiling lot's of unnecessary stuff I am just spending a lot of
> compilation time for nothing.
We compile ROOT stuff for you and it takes 10 minutes to re-compile
EVERYTHING from the scratch. The time to compile any user's code
depends of that but ROOT. I assume it is anyway less than our 300'000
C++ lines. By the way usually we re-compile /re-build some DLLs
affected and it takes about 30 - 60 secs to be completed.
>
> 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
>
It seems to me it is what we provide with our Test subdirectory
exactly. Apparently when you build your stand-alone exe it will be
linked with the stuff your code does need. (it depends of the linker
quality although). Any way you MUST supply the proper options for
ROOT include/header files. If you link against of the "static"
libraries you must re-link your code with each new version of our
libraries. If one uses DLLs he needs just replace the old ROOT DLLs
with a new one. Sure your stand-alone code will involve as many DLLs
as it really needs.
> ==> 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.....
This means you can just use Makefile (as a patern at least) we
provide with that "test" directory to get what you dream (but with
MS). Anyway you don't need any special option and any separate
"static" root library to be created. Apparently in my previous
message we were speaking about different things:
I was explaining "a theory" how to disable graphics features for
ROOT.exe not for user's stand-alone program and claimed it
isn't worth any effort. For the user's code it is done "by
automatic" with the linker as soon as that user's code doesn't
call these graphics functions itself.
> So as you can see, in my static batch lib I don't need any
===
Not lib but your stand-alone batch program.
=== =========== =======
> So as you mentioned, a static ROOT lib for MS-DOS would be ok for me,
So far even the current LIBs + DLLs were Ok for you.
> 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).
In fact you are asking us not static libraries but g++ compiled
code under Win32. It had been discussed already. We have no manpower
and will to do this, but we do provide our source and allow everyone
to compile his own version with his favorite tool too.
I hope my team will be not against to include your correction in
our code too as soon as it doesn't destroy our supported platforms
> 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.
I must be proved. But sure it entails the time to relink any user
application will be by the order (or two) of magnitude as much as
the present one.
With my best regards,
Valery
=================================================================
Dr. Valery Fine Telex : 911621 dubna su
-----------
LCTA/Joint Inst.for NuclearRes Phone : +7 09621 6 40 80
141980 Dubna, Moscow region Fax : +7 09621 6 51 45
Russia mailto:fine@main1.jinr.dubna.su
Dr. Valeri Faine
------------ Phone: +41 22 767 6468
CERN FAX : +41 22 767 7910
CH-1211 Geneva, 23 mailto:fine@mail.cern.ch
Switzerland http://nicewww.cern.ch/~fine