vtkWrapMacro

[Bill Hoffman]

I agree that the pcmaker getclasses.cxx file is a complete mess.
I have even given some thought to how to fix it.   Basically,
it needs a complete re-write.   I wanted to generate microsoft
project files instead of nmake files.  If I had the time, I think
it would only take a week or so. 

I think that the Makefile.in files should tell wether a file is
cocreate, win32, X11, abstract etc.. It would be a small change to
add a WIN32_ABSTRACT WIN32_CONCREATE X11_ABSTRACT X11_CONCREATE to
the Makefile.in.  The big complication with getclasses is that it needs 
to to dependency checking so it can break up the graphics libraries.    


Please do not check in your typemacro.   It uses the ansi typeid stuff,
that is not supported yet by all the compilers.   In most compilers it
requires a flag to turn it on, and libraries made with it on, are not
compatible with ones made without it....

I do have one question about it, where does the thisClass come from?
I thought that the typeid stuff needed an object pointer.  Right now
in VTK if you have a pointer to an object you can ask if it inherits
from another object.


Conclusions:

1. getclasses/pcmaker needs a re-write with changes so the Makefiles and
not hard coded lists of classes from getclasses.cxx determine X11 or Win32 
files.  If you are interested, I can work on this redesign with you.
As I have already started the design,  but have not had time to 
implement the it, I would welcome some help.

2. The typeid stuff can not go into VTK because of older compilers.



At 03:08 PM 4/3/00 +0100, John Biddiscombe wrote:
>I have a suggestion regarding the tcl wrapping etc etc.
>
>I've been working quite hard at generating an automatic means of wrapping
>filters with tcl and combining this with my own wrapping process.
>
>How about 
>
>vtkWrapMacro(thisClass,ParentClass,Win32,Abstract/Concrete,Header/cxx,wrapTc
>lYes,Wrap...)
>
>it could expand to nothing in c++ but provide an easy hook for the parsing
>process in pcmaker/GetClasses and in vtk\Wrap.
>
>I'm sure it isn't necessary, but the code in getclasses looks dreadful.
>
>The main reason is for those of us that have developed large numbers of our
>own filters (60+ now) and don't want to put them in vtk\local, but do want
>to automatically wrap them in tcl.
>
>By providing a wrapMacro with some general information
>Win32 Specific. X specific. Abstract ot concrete etc etc
>The dependence on the makefile.in is reduced in common/graphics/imagine etc
>etc 
>
>(I've made a pcmaker type program which will scan directories for files
>vtk*.h and if there was a vtkWrapMacro(...) in the header for each class,
>it'd be trivial to include them in the tcl wrapping etc etc.) Users need
>only supply the directory of their own classes and off they go. Currently,
>I have to have the user manually click checkboxes for each vtk*.h file it
>finds and enter
>wrapTcl yes/No
>Win32 only yes/no
>Abstract/Concrete etc etc
>
>I guess you could argue that each directory needs only a makefile.in file
>to achieve the same goal, but the code in GetClasses.cxx proves this is
>nonsense!
>
>It seems to me that tcl wrapping should only take place for concrete
>classes, but if a function is declared in an abstract base class, then it
>needs to be pulled in and parsed. Using the above macro would give you the
>superclass name (like vtkTypeMacro) and you could pull it in and parse it.
>Only concrete classes would be scanned at all and the exports section of
>vtktcl.dll might be better. (?)
>
>John B
>
>PS. Ive added my own Macro to vtkSetGet.h vtkTypeMacro
>
>static int InheritsFrom(const char *Name) {
>         if (!strcmp(typeid(thisClass).name(),Name)) return 1;
>         else if(!strcmp(typeid(thisClass).name(),"vtkObject")) return 0;
>         else return superclass::InheritsFrom(Name);
>} 
>
>this allows you to call
>
>vtkCellLocator::InheritsFrom("vtkLocator");
>
>and get a boolean answer. I find it very useful when you want to query
>inheritance but have no pointers available.
>
>Just a thought, any comments. I use it to pass pointers like
>
>CanAcceptDragDrop(@vtkCellLocator::InheritsFrom,"classname");
>
>a bit obscure I realize, but would anyone else use it?