[vtk-developers] Wrapping/Tools

[David Cole]

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.
>
>  - David
>


Well, you should be able to have an extra utility library within a module,
shouldn't you? Is there anything that prevents that?

If necessary, make vtkWrapperTools an empty/dummy library (I don't know if
it's necessary or not), and have another vtkPrivateWrapperTools library
that the language wrappers link to.

Other than vigilance via gerrit, I don't know of a mechanism to prevent
somebody from linking to a particular library, whether it be a primary
module library or not.

I'll be quiet now, and let folks with more intimate knowledge of the
modularization effort chime in. :-)


David C.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/vtk-developers/attachments/20120621/04c7b3e2/attachment.html>