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

[Dominique Belhachemi]

My use case differs from the traditional use case in one point. I
always have to turn off the superbuild process. Otherwise I would pull
all kind of unknown and potentially dangerous sources into the build
process. Instead I am using well maintained Debian packages which are
used by a lot of other applications.

I can see the advantage of using superbuild in the development phase
of Slicer. It allows easy patching of underlying libraries like ITK.
If the patch is working well they should be applied to the upstream
trunk asap. This way, Slicer will be compatible with the next ITK
release. Shipping a forked version of ITK within a Slicer package is
*not* an option for me. I rely heavily on Debian's ITK package. It is
in a very good shape and also supports newer versions of gdcm.

It would be good if patches needed by Slicer can be applied, tested,
and released with the next ITK3.xx version. Otherwise Slicer user
would have to live with the slower IO methods.

CTK is a new library, I don't see any problems there right now. The
only thing what has to be kept in mind is to backport local changes to
libraries like VTK,ITK,etc..

Let's send Slicer specific ITK patches to gerrit. I am sure ITK
developer will review them and provide good feedback.

Cheers
Dominique



On Tue, Jul 19, 2011 at 10:35 PM, Jean-Christophe Fillion-Robin
<jchris.fillionr at kitware.com> 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
>
>