Re: [ROOT] Re: CINT init_cint after scratch_all?

From: Christoph Bugel (chris@tti-telecom.com)
Date: Sun Oct 21 2001 - 11:54:59 MEST


I *finally* had some time to fix this ;)

In general it seems to work now, but I am having some problem still. I
will need to investigate some more before I will bother the list with
them ;), but if there is something obviously wrong with the following or
something I seem to be missing, please let me know.

what I did:

- I noticed that G__init_cint calls G__globalsetup, which is defined in
  G__setup.c

- G__globalsetup behaved differently for windows and Unix: On unix it
  called G__cpp_setup (#if G__CPPLINK_ON) and on windows it did nothing.

- This explains why on windows my own classes where forgotten by cint
  after G__scratch_all, and not recognized even after a new G__init_cint,
  whereas on Unix it worked. (Windows used the Dummy class in G__main.cxx.
  which does the initialization only once, ever)

- In order to fix my windows problem, and to have the  same sources for
  all platforms, I changed G__setup.c to always call G__cpp_setupMYCLASS,
  which initializes my own classes. (#if G__CPPLINK_ON, so that it doesn't
  interfere with the pure cint build)

- Therefore I thought I could throw away G__main.cxx. (I don't know why
  it uses G__set_p2fsetup(G__cpp_setupMYCLASS) ? is that different then
  simply G__cpp_setupMYCLASS ?

- As far as I understand, whenever G__init_cint is called I want to  make
  sure G__cpp_setupMYCLASS is called. If that happens, I should be ok.
  All the rest are just technical 'build system' issues. Maybe this
  assumption is wrong? The above changes seem to work in so far that cint
  now knows my classes ven after multiple scratch/init pairs, but there
  some things I do with debugging (G__stepmode) seem to work only for the
  first time, and no more after I did scratch/init. again, I first have
  to make a better diagnose myself here.

Thanks,
Christoph



On Mon 2001-07-09, Masaharu Goto wrote:
> Hello Christoph,
> 
> Thank you very much for your message. 
> 
> First, I'd like you to send Cint related requests to
> rootdev@pcroot.cern.ch.  I am not subscribing roottalk
> right now. Fons forwarded me your message.
> 
> Your question is about dictionary initialization.
> 
> 4 different dictionary initialization schemes are implemented
> in Cint and ROOT. Each scheme is good for specific use-case
> and environment.  Normally, the best method is choosen by makecint
> or rootcint, hence, users do not need to care.  In your case,
> however, you try to tailor the solution and ending up mixing
> incompatible dictionary initialization scheme.  This is not 
> your fault. It is due to a very complex scheme I implemented.
> Let me explain what is happening in your case.
> 
> For Windows + makecint -o option,  makecint creates a G__main.cxx
> source which has a dictionary initialization class. Please find
> G__main.cxx and see what is in there.  There is a class and a 
> static object is defined. When you start the process, this object
> is initialized by a constructor. In this constructor, dictionary
> initialization routine is registered into Cint. This initialization
> occurs only at the first G__init_cint call. Then, later when you 
> call G__init_cint again, dictionary is reset and never 
> re-initialized.
> 
> Here are some ideas to solve this problem. It is clear that above
> scheme does not work for you.  I recommend you to call 
> G__cpp_setupXXX explicitly in your application after each 
> G__init_cint call.  
> 
> I hope this works for you.
> 
> Thank you
> Masaharu Goto
> 
> 
> >Date: Sun, 8 Jul 2001 18:30:13 +0300
> >From: Christoph Bugel <chris@tti-telecom.com>
> >To: roottalk@pcroot.cern.ch
> >Subject: [ROOT] Re: CINT init_cint after scratch_all?
> >User-Agent: Mutt/1.2.5i
> >
> >Actually, this isn't caused by scratch_all: I can now reproduce it like this 
> as well:
> >
> >works:
> >======
> >G__init_cint("");
> >G__exec_text("Data d1;"); // works. (my "Data" class is recognized)
> >
> >doesn't work:
> >=============
> >G__init_cint("");
> >G__init_cint("");
> >G__exec_text("Data d1;"); // error. class Data not known
> >
> >doesn't work:
> >=============
> >G__init_cint("");
> >G__scratch_all();
> >G__init_cint("");
> >G__exec_text("Data d1;"); // error. class Data not known
> >
> >Any ideas?
> >Thanks
> >
> >
> >
> >On Sun 2001-07-08, Christoph Bugel wrote:
> >> (note: I use cint interpreter code, but not root)
> >> 
> >> When I call G__scratch_all, cint seems to forget about my own classes. What
>  
> I
> >> do is this: I have my own class "Data" defined in file Data.h and Data.cxx.
>  
> I
> >> compile and link this class into my own compiled application, *and* I link
> >> libcint into my application, *and* I also link a generated file G__cpp_data
> .
> cxx
> >> into my application. This last file is generated by a cint commandline wher
> e I
> >> tell it about Data.h, (I think this is called a dictionary)
> >> 
> >> My compiled code, in general, does this:
> >> 
> >> G__init_cint("");
> >> G__exec_text("Data d1;");   // works fine, cint *already* knows my class
> >> G__scratch_all();
> >> G__init_cint("");
> >> G__exec_text("Data d1;");   // fails: class Data is not known
> >> G__scratch_all();
> >> 
> >> Seems to me like cint forgot about my class "Data", when I called 
> scratch_all.
> >> This occured on windows, but on Linux it worked fine, so it makes me wonder
> >> whether it is correct behaviour at all for scratch_all to forget my classes
> .
> >> Maybe it is because my makefile on windows is different.  Maybe I did 
> something
> >> wrong -- I don't exactly understand what main/G__setup.c and main/G__main.c
>  
> are
> >> for, but I used both.
> >> 
> >> Any info is appreciated :)
> >> 
> >
> >----- End forwarded message -----
> >
> >-- 
> >Org:    CERN, European Laboratory for Particle Physics.
> >Mail:   1211 Geneve 23, Switzerland
> >E-Mail: Fons.Rademakers@cern.ch              Phone: +41 22 7679248
> >WWW:    http://root.cern.ch/~rdm/            Fax:   +41 22 7677910



This archive was generated by hypermail 2b29 : Tue Jan 01 2002 - 17:51:03 MET