[vtk-developers] Wrapping/Tools

David Gobbi david.gobbi at gmail.com
Thu Jun 21 15:43:29 EDT 2012


On Thu, Jun 21, 2012 at 1:35 PM, David Cole <david.cole at kitware.com> wrote:
> On Thu, Jun 21, 2012 at 3:29 PM, David Gobbi <david.gobbi at gmail.com> wrote:
>>
>> Going with the general flow of modularization, I'm wondering if the
>> wrapping tools like Wrapping/vtkWrapPython.c should be moved to a new
>> directory called Wrapping/Tools.
>>
>> Pros: A Wrapping/Tools directory would nicely fit the two-level
>> directory structure that VTK has adopted.
>>
>> Cons: Wrapping/Tools can't be made into a proper "module" as far as I
>> understand it, because it isn't a library for other modules to link
>> to.  Rather, it is a set of executables that other modules need to
>> execute during the build process.
>>
>> Main reason that I'm wondering is that I have some changes to the
>> wrapper tools that I want to merge, and they include an overhaul of
>> Wrapping/CMakeLists.txt.  So it seems to make sense that if the
>> wrapper tools are going to be moved, then the move should be done
>> prior to the merge.
>>
>>  - David
>
> This sounds reasonable to me. The "con" you list doesn't seem like that much
> of a con to me. Even if you have to make a dummy module library with a dummy
> function in it, I'd still say the pro outweighs it.

Well, you see, the issue is that I do want to have a library in it...
I want to have a "vtkWrapperTools.a" library that vtkWrapPython,
vtkWrapJava, etc. all link to.  A static library, of course, because
having build tools link to a dynamic library (especially for
cross-compiles) is undesirable.  But no other VTK modules should ever
link to vtkWrapperTools.a.

I.e. I want Wrapping/Tools to contain a library that isn't a "module" library.

 - David



More information about the vtk-developers mailing list