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

[Jean-Christophe Fillion-Robin]

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