[vtk-developers] Wrapping/Tools

Marcus D. Hanwell marcus.hanwell at kitware.com
Thu Jun 21 15:56:56 EDT 2012


On Thu, Jun 21, 2012 at 3:43 PM, David Gobbi <david.gobbi at gmail.com> wrote:
> 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.
>
You can make a module called vtkWrapperTools, and have other modules
COMPILE_DEPEND upon it. So you could get the dependency
tracking/automatic activation of the module. The vtkEncodeString
utility is similar in that sense, and we could make adjustments if
necessary.

I was tempted to look at doing something like that, but didn't have
the time to fundamentally change the way the wrapping tools were
built.

Marcus



More information about the vtk-developers mailing list