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

[Matt McCormick]

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
>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.itk.org/mailman/private/insight-developers/attachments/20110719/c24bf970/attachment.htm>