<div class="gmail_quote">On Thu, Jun 21, 2012 at 3:43 PM, David Gobbi <span dir="ltr"><<a href="mailto:david.gobbi@gmail.com" target="_blank">david.gobbi@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="im">On Thu, Jun 21, 2012 at 1:35 PM, David Cole <<a href="mailto:david.cole@kitware.com">david.cole@kitware.com</a>> wrote:<br>
> On Thu, Jun 21, 2012 at 3:29 PM, David Gobbi <<a href="mailto:david.gobbi@gmail.com">david.gobbi@gmail.com</a>> wrote:<br>
>><br>
>> Going with the general flow of modularization, I'm wondering if the<br>
>> wrapping tools like Wrapping/vtkWrapPython.c should be moved to a new<br>
>> directory called Wrapping/Tools.<br>
>><br>
>> Pros: A Wrapping/Tools directory would nicely fit the two-level<br>
>> directory structure that VTK has adopted.<br>
>><br>
>> Cons: Wrapping/Tools can't be made into a proper "module" as far as I<br>
>> understand it, because it isn't a library for other modules to link<br>
>> to. Rather, it is a set of executables that other modules need to<br>
>> execute during the build process.<br>
>><br>
>> Main reason that I'm wondering is that I have some changes to the<br>
>> wrapper tools that I want to merge, and they include an overhaul of<br>
>> Wrapping/CMakeLists.txt. So it seems to make sense that if the<br>
>> wrapper tools are going to be moved, then the move should be done<br>
>> prior to the merge.<br>
>><br>
>> - David<br>
><br>
</div><div class="im">> This sounds reasonable to me. The "con" you list doesn't seem like that much<br>
> of a con to me. Even if you have to make a dummy module library with a dummy<br>
> function in it, I'd still say the pro outweighs it.<br>
<br>
</div>Well, you see, the issue is that I do want to have a library in it...<br>
I want to have a "vtkWrapperTools.a" library that vtkWrapPython,<br>
vtkWrapJava, etc. all link to. A static library, of course, because<br>
having build tools link to a dynamic library (especially for<br>
cross-compiles) is undesirable. But no other VTK modules should ever<br>
link to vtkWrapperTools.a.<br>
<br>
I.e. I want Wrapping/Tools to contain a library that isn't a "module" library.<br>
<span class="HOEnZb"><font color="#888888"><br>
- David<br>
</font></span></blockquote></div><div><br></div><br><div>Well, you should be able to have an extra utility library within a module, shouldn't you? Is there anything that prevents that?</div><div><br></div><div>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.</div>
<div><br></div><div>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.</div><div><br></div><div>I'll be quiet now, and let folks with more intimate knowledge of the modularization effort chime in. :-)</div>
<div><br></div><div><br></div><div>David C.</div><div><br></div>