[vtk-developers] Adding VTKData and VTKLargeData as optional submodules

[Marcus D. Hanwell]

I will leave that to Berk, I was clarifying what was actually being
suggested. I listed pros/cons as we saw them, such as once I merge in
a topic that changes the baseline all topics branched from an earlier
master will begin to fail for no particular reason. This may or may
not be that much of an issue.

Once we have the time then I (and I believe Berk) am totally behind
moving to the external data solution, which is superior to this
approach and seems to have had most of the kinks worked out by now.

Marcus

On Wed, Mar 6, 2013 at 1:39 PM, Bill Lorensen <bill.lorensen at gmail.com> wrote:
> My last comments.
>
> Why bother with an interim solution? Why not wait until the ITK solution can
> be made.
>
> The sub-module approach will require some change in process which will
> eventually be replaced with another change in process.
>
> One good thing about the current approach. It gives a reviewer a chance to
> see the changes in the output intorduced by a topic. For example, in a
> recent gerrit topic, I was able to comment that the new images looked worse
> than the original.
>
> Bill
>
>
> On Wed, Mar 6, 2013 at 1:29 PM, Marcus D. Hanwell
> <marcus.hanwell at kitware.com> wrote:
>>
>> On Wed, Mar 6, 2013 at 10:47 AM, Jean-Christophe Fillion-Robin
>> <jchris.fillionr at kitware.com> wrote:
>> > Hi Marcus,
>> >
>> > Since by default, it seems the ExternalProjects CMake module is doing a
>> > recursive update on sub-modules, how would these VTK sub-modules be
>> > considered as optional in that case ?
>> >
>> > See
>> >
>> > http://cmake.org/gitweb?p=cmake.git;a=blob;f=Modules/ExternalProject.cmake;h=bf2892b741e0d5551ecd310c461289a09e214cf6;hb=HEAD#l318
>>
>> External project could be modified not to do that, and having them
>> there is unlikely to hurt things (but would increase time to
>> checkout).
>> >
>> > When building project that depends on VTK, we can not assume VTK will be
>> > built with testing enabled.
>>
>> We are not, and external project is one possible way of obtaining VTK
>> that could easily be modified.
>> >
>> > Instead wouldn't it make more sens to generalize what ITK folks are
>> > doing to
>> > make its easy to reuse for other projects ?
>> >
>> I don't know how much clearer I can be, I said in the original post
>> that after discussing this with Berk we agree that external data is
>> the way to go long term but he doesn't feel that we have the
>> time/resources (correct me if I am wrong Berk) to do that at this
>> time. This was suggested as a possible interim solution - we are well
>> aware of the ITK/CMake external data solution.
>>
>> Marcus
>
>
>
>
> --
> Unpaid intern in BillsBasement at noware dot com