Hi,
> When using the ACLIC (Automatic Compiler Linker Interface to CINT),
> you do not need things like:
> #ifndef __CINT__
> (...)
Well, this is only half true as far as I can see.
Sometimes it is really needed to protect CINT (ROOTCINT ?) from some
include files, as it cannot parse them properly.
Most probably CINT (ROOTCINT ?) has little problems with "standard" ROOT
include files, still there are some that it does not like very much.
One of them, that I know of, is Rtypes.h (just try to #include it and you
will get 3 warnings "Re-initialization ignored const").
The proposed solution (also on page 95 in chapter "Moving between
Interpreter and Compiler" in the Users_Guide_07.pdf) is :
1. in case neither CINT nor ROOTCINT should see include files :
#ifndef __CINT__
2. in case CINT should not see them ,but ROOTCINT should :
#if !defined(__CINT__) || defined (__MAKECINT__)
Thus my original questions ("Users_Guide_07.pdf (3)") remain still valid.
First - the manual suggests that ROOTCINT must see Rtypes.h (and CINT
should not), but from my experience it is not really true. They BOTH live
well without seeing Rtypes.h. (I often do :
#ifndef __CINT__
#include "Rtypes.h"
#endif
as the compiler needs to know what different types mean like "Double_t",
macros like "ClassDef", but neither CINT nor ROOTCINT seem to care.)
Second - a comprehensive "list" of "standard" ROOT files that the ROOTCINT
needs to see would be nice in this place (and a "list" of files that the
CINT does not like, too).
Jacek.
P.S. One could recommend also :
http://root.cern.ch/root/Cint.phtml?extlib
http://root.cern.ch/root/Cint.phtml?limitations
Jacek.
This archive was generated by hypermail 2b29 : Tue Jan 01 2002 - 17:50:37 MET