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

[Stephen Aylward]

Hi Brad,

This is really great help!  Thank you!

I think we should pass on the ImageIO changes until I submit them as
an IJ article, get reviews on it, etc.

A 3.20.1 tag seems like very good idea and it seems like it should be
sufficient.

Thank you!
Stephen

On Tue, Jul 19, 2011 at 11:16 PM, Bradley Lowekamp
<blowekamp at mail.nih.gov> wrote:
> 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
>
>



-- 

==============================
Stephen R. Aylward, Ph.D.
Director of Medical Imaging Research
Kitware, Inc. - North Carolina Office
http://www.kitware.com
stephen.aylward (Skype)
(919) 969-6990 x300