<html><head><style data-externalstyle="true">
p.MsoListParagraph, li.MsoListParagraph, div.MsoListParagraph {
margin-top:0in;
margin-right:0in;
margin-bottom:0in;
margin-left:.5in;
margin-bottom:.0001pt;
}
p.MsoListParagraphCxSpFirst, li.MsoListParagraphCxSpFirst, div.MsoListParagraphCxSpFirst, p.MsoListParagraphCxSpMiddle, li.MsoListParagraphCxSpMiddle, div.MsoListParagraphCxSpMiddle, p.MsoListParagraphCxSpLast, li.MsoListParagraphCxSpLast, div.MsoListParagraphCxSpLast {
margin-top:0in;
margin-right:0in;
margin-bottom:0in;
margin-left:.5in;
margin-bottom:.0001pt;
line-height:115%;
}
</style></head><body><div data-externalstyle="false" style="font-family:Calibri,'Segoe UI',Meiryo,'Microsoft YaHei UI','Microsoft JhengHei UI','Malgun Gothic','Khmer UI','Nirmala UI',Tunga,'Lao UI',Ebrima,sans-serif;font-size:16px;"><div>I know I’m late, but I’ll chime in now.</div><div> </div><div>I agree with Bill L. here: why bother with an interim “solution”.</div><div> </div><div>It’s just busy work.</div><div> </div><div>It works “well enough” right now without anybody having to do anything.</div><div> </div><div>Leave well enough alone until the ExternalData approach can be implemented.</div><div data-focusfrompointer="true"> </div><div data-focusfrompointer="true"> </div><div data-signatureblock="true"> </div> <div style="border-top-color: rgb(225, 225, 225); border-top-width: 1px; border-top-style: solid;"> <strong>From:</strong> Marcus D. Hanwell<br> <strong>Sent:</strong> March 6, 2013 1:47 PM<br> <strong>To:</strong> Bill Lorensen<br> <strong>CC:</strong> VTK Developers<br> <strong>Subject:</strong> Re: [vtk-developers] Adding VTKData and VTKLargeData as optional submodules<br> </div> <div> </div>I will leave that to Berk, I was clarifying what was actually being<br>suggested. I listed pros/cons as we saw them, such as once I merge in<br>a topic that changes the baseline all topics branched from an earlier<br>master will begin to fail for no particular reason. This may or may<br>not be that much of an issue.<br><br>Once we have the time then I (and I believe Berk) am totally behind<br>moving to the external data solution, which is superior to this<br>approach and seems to have had most of the kinks worked out by now.<br><br>Marcus<br><br>On Wed, Mar 6, 2013 at 1:39 PM, Bill Lorensen <bill.lorensen@gmail.com> wrote:<br>> My last comments.<br>><br>> Why bother with an interim solution? Why not wait until the ITK solution can<br>> be made.<br>><br>> The sub-module approach will require some change in process which will<br>> eventually be replaced with another change in process.<br>><br>> One good thing about the current approach. It gives a reviewer a chance to<br>> see the changes in the output intorduced by a topic. For example, in a<br>> recent gerrit topic, I was able to comment that the new images looked worse<br>> than the original.<br>><br>> Bill<br>><br>><br>> On Wed, Mar 6, 2013 at 1:29 PM, Marcus D. Hanwell<br>> <marcus.hanwell@kitware.com> wrote:<br>>><br>>> On Wed, Mar 6, 2013 at 10:47 AM, Jean-Christophe Fillion-Robin<br>>> <jchris.fillionr@kitware.com> wrote:<br>>> > Hi Marcus,<br>>> ><br>>> > Since by default, it seems the ExternalProjects CMake module is doing a<br>>> > recursive update on sub-modules, how would these VTK sub-modules be<br>>> > considered as optional in that case ?<br>>> ><br>>> > See<br>>> ><br>>> > http://cmake.org/gitweb?p=cmake.git;a=blob;f=Modules/ExternalProject.cmake;h=bf2892b741e0d5551ecd310c461289a09e214cf6;hb=HEAD#l318<br>>><br>>> External project could be modified not to do that, and having them<br>>> there is unlikely to hurt things (but would increase time to<br>>> checkout).<br>>> ><br>>> > When building project that depends on VTK, we can not assume VTK will be<br>>> > built with testing enabled.<br>>><br>>> We are not, and external project is one possible way of obtaining VTK<br>>> that could easily be modified.<br>>> ><br>>> > Instead wouldn't it make more sens to generalize what ITK folks are<br>>> > doing to<br>>> > make its easy to reuse for other projects ?<br>>> ><br>>> I don't know how much clearer I can be, I said in the original post<br>>> that after discussing this with Berk we agree that external data is<br>>> the way to go long term but he doesn't feel that we have the<br>>> time/resources (correct me if I am wrong Berk) to do that at this<br>>> time. This was suggested as a possible interim solution - we are well<br>>> aware of the ITK/CMake external data solution.<br>>><br>>> Marcus<br>><br>><br>><br>><br>> --<br>> Unpaid intern in BillsBasement at noware dot com<br>_______________________________________________<br>Powered by www.kitware.com<br><br>Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html<br><br>Follow this link to subscribe/unsubscribe:<br>http://www.vtk.org/mailman/listinfo/vtk-developers<br><br></div></body></html>