[Insight-users] gcc-xml
Neil Killeen
Neil.Killeen@atnf.csiro.au
Tue, 26 Nov 2002 13:40:37 +1100 (EST)
G'day Luis
one followup.
On Mon, 25 Nov 2002, Luis Ibanez wrote:
>
> The Tcl wrapping that is provided by Cable makes
> possible to use ITK classes from Tcl. Cable uses
> gcc-xml internally in order to parse C++ code and
> obtain declaration in XML. Building gcc-xml is
> surprisingly easy. However if you want to avoid
> this step, you can simply download binary versions
> from:
>
> http://www.gccxml.org/HTML/Download.html
>
>
> Note that the Tcl wrapping generated by Cable is
> not the same as the traditional Tcl wrapping in
> VTK. That is, by wrapping with Cable you will not
> get VTK and ITK in the same Tcl environment.
> You will have to wrap VTK using Cable instead of
> the traditional Tcl wrappers.
>
> Some of the example-applications have followed
> another path, which is to insert isolated ITK
> filters inside VTK custom filters, then wrap
> those new VTK filter into Tcl using the traditional
> VTK Tcl-wrapping. This is done in the following
> applications:
>
>
>
> This secondary approach for wrapping is a
> common source of confusion.
>
indeed. it is particularly confusing because in the ccmake
interface, one sees
ITK_WRAP_TCL - Build Tcl wrapper support.
VTKITK_WRAP_TCL - Wrap classes into the TCL interpreted language.
it was opaque to me what the difference was. i assume now,
following your explanation, that ITK_WRAP_TCL is the Cable wrapping
capability, and VTKITK_WRAP_TCL is the VTK 'style' of wrapping
that some of the ITK applications use. Is that correct ?
(I gather the Cable wrapping is more powerful as it enables
you to bind to any itk class).
This means I can turn VTKITK_WRAP_TCL on without needing gccxml
and Cable which is required only if I turn ITK_WRAP_TCL on.
I was thinking that as well as the FAQ, perhaps the useful 'Related
Software' page could be expanded to hold a little more detail (such as
some of the things in your email) to make it clearer the relationship
between ITK and the cooperating toolkits, in particular
their linkage to the CMake file.
I realize, like everything, it's a matter of priority (I don't
know what the ITK planning and prioritization process is).
However, I'd argue that the place where documentation should
be the best is when you first encounter a system. This minimizes
misunderstandings about the system, and hence minimizes the amount
of 'beginners' questions folks like you need to handle (and you
handle an awful lot of enquires, i should say !).
cheers
Neil