[Insight-developers] [slicer-devel] Strawman: ITK 3 tag to use with slicer

[Bradley Lowekamp]

Hello,

 I just looked at Slicer branch ( https://github.com/Slicer/ITK/commits/slicer-4.0 ).

1) The topic "fix-gcc46-compile" is already in the ITK's release branch.

2) I just pushed JC's "fix-vnl-64bits-compile" to gerrit:
http://review.source.kitware.com/#change,2142

3) The remaining commits  are in the topic "reader-speedup-reuse-buffer" ( the best I can tell ). I believe this is just a performance improvement. And with out this Slicer should still compile against the gerrit' proposed release. It appears that additional work needs to be done on this topic to get it changes coverd by testing and supported by any itk imageIO.

If the gerrit topic is merged into itk release, and a 3.20.1 tag was made. Would that be sufficient?

Brad

On Jul 19, 2011, at 10:35 PM, Jean-Christophe Fillion-Robin wrote:

> I would like to include Dominique Belhachemi in the discussion, he has been a debian packaged for now several year and I am sure he would provide insightful comments regarding the most appropriate of handling the packaging of a Superbuild based application like Slicer.
> 
> Dominique> 
>    What do you think ? 
>    Could you comment on use case 3 ? 
>    How would you proceed to efficiently, simply and robustly package an application like Slicer ?
>    What are the implication regarding the dependent project (ITK, CTK, ... ) ? 
> 
> Thanks
> Jc
> 
> On Tue, Jul 19, 2011 at 2:13 PM, Matt McCormick <matt.mccormick at kitware.com> wrote:
> Resending, so it hits the lists....
> 
> 
> On Tue, Jul 19, 2011 at 1:43 PM, Matt McCormick <matt.mccormick at kitware.com> wrote:
> Hi JC,
> 
> With default workflow to be Slicer superbuild, I don't think we ever reach Use case 3.  It encourages forking and generally promotes disorganization instead of cooperation.  In addition, if someone wants to work on other projects that use VTK/CTK/ITK, they needlessly use up CPU and hard drive resources with that approach.  As you mention, the Slicer_SUPERBUILD:OFF needs to be used and tested.  It should not only be the Debian packagers who test this.  The scenario would then be:
> 
> 
> Use case 1: You develop a Slicer module
>   Mac and Linux 
>     -> Install CTK/VTK/ITK dependencies with a package manager (just like one normally does with every other open source dependency, qt, ...), or 'make install'
>   Windows
> 
>     -> Slicer superbuild
> 
> Use case 2: You work on Slicer core feature / Add feature to VTK / CTK / ITK ..
>     ->  Work with the upstream project to get the patch merged, then use it in Slicer
> 
> 
> Use case 3: Packager (Debian, Ubuntu ... )
>     ->  They have to do nothing unusual, there is not forked code, so we get debian packages :-)
> 
> Use case 4: You use Slicer
>      -> apt-get install slicer
> 
> My humble opinion,
> 
> Matt
> 
> 
> On Mon, Jul 18, 2011 at 10:22 PM, Jean-Christophe Fillion-Robin <jchris.fillionr at kitware.com> wrote:
> To clarify, 
> 
> Use case 1: You develop a Slicer module 
>    -> Slicer superbuild
> 
> Use case 2: You work on Slicer core feature / Add feature to VTK / CTK / ITK .. 
>    -> Slicer superbuild  + sharing branch between Slicer superbuild checkout of [VTK, ITK, ..] and your local checkouts of [VTK, ITK, CTK, ...]
>    -> Slicer superbuild + pass your custom build using ITK_DIR, VTK_DIR ... 
>    -> combination of both
> 
> Use case 3: Packager (Debian, Ubuntu ... )
>   -> Simply build Slicer with Slicer_SUPERBUILD:OFF 
>   -> It will then use the system VTK, ITK, ... 
> 
> I think all use cases are addressed. 
> 
> Note: The case Slicer_SUPERBUILD:OFF will have to be tested. I guess this could / will be done with the help of debian auto-packaging dashboard. ( As an example and thanks to the work of Dominique, you can see the one of CTK - see [1] and [2])
> 
> Questions:
>   
>  Can somebody agree on validating / testing / leading / benchmarking the Improvement of the image reader ? 
> 
>  Am I missing something ?
> 
> Jc
> 
> [1] http://packages.qa.debian.org/c/ctk.html
> [2] https://buildd.debian.org/status/package.php?p=ctk&suite=experimental
> 
> 
> 
> 
> -- 
> +1 919 869 8849
> 
> _______________________________________________
> Powered by www.kitware.com
> 
> Visit other Kitware open-source projects at
> http://www.kitware.com/opensource/opensource.html
> 
> Kitware offers ITK Training Courses, for more information visit:
> http://kitware.com/products/protraining.html
> 
> Please keep messages on-topic and check the ITK FAQ at:
> http://www.itk.org/Wiki/ITK_FAQ
> 
> Follow this link to subscribe/unsubscribe:
> http://www.itk.org/mailman/listinfo/insight-developers

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.itk.org/mailman/private/insight-developers/attachments/20110719/35533236/attachment.htm>