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

Stephen Aylward stephen.aylward at kitware.com
Mon Jul 18 21:39:04 EDT 2011 

Hi Bill,

>  It would be difficult although not impossible to accept the slicer
> repo as ITK 3.22 (3.21 is a development branch, not a release brnch).
> My concern is the lack of testing and dashboards for 3.22.

Ah - so this was the mis communication...and it was my fault.   I
phrased things very poorly.  Of course I wouldn't expect the
Slicer-ITK repo to be the ITK repo.   Nor would I expect changes to be
made untested, etc etc.    Those kinds of things are trivial if we
agree to move forward with porting the changes (and creating tests,
etc) to create a release version of ITK that supports Slicer
packaging.

> As for debian packaging in the short term, I do not see a tested use
> case that supports an installed ITK system. I do not see the usual
> support for an ITK system build in the Slicer build.

This is really good input on how to design Slicer and its tests.
Slicer is unusual in that we make deviating from a standard build to
be an obscure process on purpose.   We want people to do what is
standard - and yet we also want to get Slicer distributed broadly
(e.g., as a Debian package).   We'll need to walk the line carefully.

> We should be able to work this out. As I said before there is so much
> shared interest, community and company involvement.

Agreed.   Seems like this would be good for everyone.

>
> Bill
>
> On Mon, Jul 18, 2011 at 7:22 PM, Stephen Aylward
> <stephen.aylward at kitware.com> wrote:
>> Hi Bill,
>>
>> I guess the common theme I'm picking up in your emails is that in
>> moving from release ITKv3.20 to ITKv3.21 you're against making the
>> changes necessary to support the packaging of Slicer for Debian
>> because creating a Debian package is an unusual case for Slicer, and
>> therefore an unusual case for ITK, and therefore not something that
>> should be considered in an ITK release.
>>
>> I can see your point.  Supporting Slicer really isn't the ITK
>> developers' job.  Slicer developers can offer fixes, but those fixes
>> do not have to be accepted by the ITK developers.   It is kind of
>> incestuous that the ITK and Slicer development teams mix as much as
>> they do, and I can see how some could argue that ITK development,
>> Slicer development, etc should be kept apart so as not to bias one
>> another too much - I personally don't think that is best, but I do see
>> how some could think that and there are valid arguments along those
>> lines.
>>
>> In the end, what needs to be done is what is best for the medical
>> image analysis community as a whole.  I'll defer it to y'all on this.
>>
>> Stephen
>>
>> PS> Sorry if I have misinterpreted your emails.  It really could be a
>> misunderstanding on my part - or perhaps there is a misunderstanding
>> on what is needed for packaging or what the Slicer community is
>> proposing for ITKv3.21?
>>
>> As JC said, the changes Slicer needs for it to switch to ITKv3.21 are
>> the 13 listed at:
>> https://github.com/Slicer/ITK/commits/slicer-4.0
>> The features are
>> 1) Don't require IO methods to copy data from the reader's internal
>> data storage to the reader's output image, instead just copy the
>> buffer pointer, when the pixel types in both are the same.
>> 2) Fix VXL to support 64bit compilation
>> 3) Update ITK to support the latest releases of gcc (gcc4.6)
>>
>> On Mon, Jul 18, 2011 at 5:59 PM, Bill Lorensen <bill.lorensen at gmail.com> wrote:
>>> I'm sorry, what is the way?
>>>
>>> On Mon, Jul 18, 2011 at 5:56 PM, Stephen Aylward
>>> <stephen.aylward at kitware.com> wrote:
>>>> This is the way every debian user would use slicer...if they use the slicer
>>>> package.   These packages are installed via a simple package-add/apt-get
>>>> command.  It is really quite easy.  Particularly for apps, like slicer.
>>>>
>>>> I don't think debian packaging should be viewed as an unsupported or an
>>>> odd/advanced case.
>>>>
>>>> All of our open source packages should shoot for being debian packages and
>>>> easy to install/use in the ways that have the greatest impact.
>>>>
>>>> S
>>>>
>>>> On Jul 18, 2011 5:42 PM, "Bill Lorensen" <bill.lorensen at gmail.com> wrote:
>>>>> That is my point. Are we trying to address a sophisticated use case or
>>>>> one that a normal user might encounter.
>>>>>
>>>>> Is there an existing dashboard that is using a system itk, vtk, ctk,
>>>>> etc...
>>>>>
>>>>> On Mon, Jul 18, 2011 at 5:36 PM, Julien Finet <julien.finet at kitware.com>
>>>>> wrote:
>>>>>> There is no SLICER_USE_SYSTEM_ITK...
>>>>>> However, if you don't provide any ITK_DIR, it will try to find
>>>>>> (find_package) an ITK directory. So if it's installed on your machine
>>>>>> (and
>>>>>> the only ITK on the machine), it should use it automatically.
>>>>>> Julien.
>>>>>>
>>>>>> On Mon, Jul 18, 2011 at 5:30 PM, Bill Lorensen <bill.lorensen at gmail.com>
>>>>>> wrote:
>>>>>>>
>>>>>>> So can I do this now?
>>>>>>>
>>>>>>> I'd like to test it.
>>>>>>>
>>>>>>> Bill
>>>>>>>
>>>>>>> On Mon, Jul 18, 2011 at 5:19 PM, Stephen Aylward
>>>>>>> <stephen.aylward at kitware.com> wrote:
>>>>>>> > Hi Bill,
>>>>>>> >
>>>>>>> > Great way of phrasing it....this is exactly the use case we're
>>>>>>> > shooting for.   It is the use-case needed for the Debian packaging.
>>>>>>> > Each Debian package should not provide its own version of ITK, VTK,
>>>>>>> > etc - they should be shared.
>>>>>>> >
>>>>>>> > Stephen
>>>>>>> >
>>>>>>> > On Mon, Jul 18, 2011 at 5:13 PM, Bill Lorensen
>>>>>>> > <bill.lorensen at gmail.com>
>>>>>>> > wrote:
>>>>>>> >> For example, is there a SLICER_USE_SYSTEM_ITK, SLICER_USE_SYSTEM_VTK,
>>>>>>> >> SLICER_USE_SYSTEM_CTK, etc...
>>>>>>> >>
>>>>>>> >> I don't want be a PITA, I just want to make sure that we don't spend
>>>>>>> >> time on a non-supported use-case.
>>>>>>> >>
>>>>>>> >> On Mon, Jul 18, 2011 at 5:08 PM, Bill Lorensen
>>>>>>> >> <bill.lorensen at gmail.com> wrote:
>>>>>>> >>> But who is doing this now? Is this a common use case?
>>>>>>> >>>
>>>>>>> >>> On Mon, Jul 18, 2011 at 4:33 PM, Steve Pieper <pieper at ibility.net>
>>>>>>> >>> wrote:
>>>>>>> >>>> You should be able to do it just by setting the ITK_DIR with cmake
>>>>>>> >>>> in
>>>>>>> >>>> the
>>>>>>> >>>> build directory and then remaking.
>>>>>>> >>>>
>>>>>>> >>>> On Mon, Jul 18, 2011 at 4:19 PM, Bill Lorensen
>>>>>>> >>>> <bill.lorensen at gmail.com>
>>>>>>> >>>> wrote:
>>>>>>> >>>>>
>>>>>>> >>>>> I agree about the version explosion. I wish we did not have this
>>>>>>> >>>>> diversion.
>>>>>>> >>>>>
>>>>>>> >>>>> So, do we currently support a slicer with an installed system ITK
>>>>>>> >>>>> version? How do I configure a build to use it? I'd like to try it.
>>>>>>> >>>>>
>>>>>>> >>>>> Bill
>>>>>>> >>>>>
>>>>>>> >>>>> On Mon, Jul 18, 2011 at 4:05 PM, Steve Pieper <pieper at ibility.net>
>>>>>>> >>>>> wrote:
>>>>>>> >>>>> > Hi Bill -
>>>>>>> >>>>> >
>>>>>>> >>>>> > Most developers build their own and most users will get the
>>>>>>> >>>>> > binary
>>>>>>> >>>>> > package
>>>>>>> >>>>> > of slicer that comes with ITK (and other things) pre-compiled.
>>>>>>> >>>>> > The
>>>>>>> >>>>> > special
>>>>>>> >>>>> > case is debian/ubuntu, where we'd like to be able to provide a
>>>>>>> >>>>> > slicer
>>>>>>> >>>>> > package that relies only on the standard system installed
>>>>>>> >>>>> > versions
>>>>>>> >>>>> > of
>>>>>>> >>>>> > all
>>>>>>> >>>>> > libraries.  Presumably the same approach would work for other
>>>>>>> >>>>> > linux
>>>>>>> >>>>> > distributions too, although nobody is working on those, I think.
>>>>>>> >>>>> >
>>>>>>> >>>>> > Aside from the convenience for linux distributions, I think it
>>>>>>> >>>>> > would be
>>>>>>> >>>>> > good
>>>>>>> >>>>> > practice not to have too many versions of ITK floating around.
>>>>>>> >>>>> >
>>>>>>> >>>>> > -Steve
>>>>>>> >>>>> >
>>>>>>> >>>>> > On Mon, Jul 18, 2011 at 3:43 PM, Bill Lorensen
>>>>>>> >>>>> > <bill.lorensen at gmail.com>
>>>>>>> >>>>> > wrote:
>>>>>>> >>>>> >>
>>>>>>> >>>>> >> Do not most slicer developers build their own version of ITK?
>>>>>>> >>>>> >> Or
>>>>>>> >>>>> >> do
>>>>>>> >>>>> >> they use a system ITK?
>>>>>>> >>>>> >>
>>>>>>> >>>>> >> On Mon, Jul 18, 2011 at 3:37 PM, Stephen Aylward
>>>>>>> >>>>> >> <stephen.aylward at kitware.com> wrote:
>>>>>>> >>>>> >> > Hi,
>>>>>>> >>>>> >> >
>>>>>>> >>>>> >> > Using superbuild to apply patches doesn't help create a
>>>>>>> >>>>> >> > version
>>>>>>> >>>>> >> > of
>>>>>>> >>>>> >> > ITK
>>>>>>> >>>>> >> > that can be used with the Debian package of Slicer.
>>>>>>> >>>>> >> >
>>>>>>> >>>>> >> > Perhaps the version of ITK being used with Slicer should
>>>>>>> >>>>> >> > become
>>>>>>> >>>>> >> > ITK
>>>>>>> >>>>> >> > v3.21 instead of cherrypicking from it.   I believe what your
>>>>>>> >>>>> >> > are
>>>>>>> >>>>> >> > proposing would only provide one feature difference between
>>>>>>> >>>>> >> > ITK3.20
>>>>>>> >>>>> >> > and 3.21, i.e., the ability to compile on gcc4.6 - doesn't
>>>>>>> >>>>> >> > seem
>>>>>>> >>>>> >> > like
>>>>>>> >>>>> >> > a
>>>>>>> >>>>> >> > good reason for a whole new release.   By not including the
>>>>>>> >>>>> >> > other
>>>>>>> >>>>> >> > patches that the Slicer folks are providing we loose the
>>>>>>> >>>>> >> > chance
>>>>>>> >>>>> >> > to
>>>>>>> >>>>> >> > build itk with 64bits and fix other bugs.
>>>>>>> >>>>> >> >
>>>>>>> >>>>> >> > s
>>>>>>> >>>>> >> >
>>>>>>> >>>>> >> > On Mon, Jul 18, 2011 at 3:19 PM, Bill Lorensen
>>>>>>> >>>>> >> > <bill.lorensen at gmail.com>
>>>>>>> >>>>> >> > wrote:
>>>>>>> >>>>> >> >> Folks,
>>>>>>> >>>>> >> >>
>>>>>>> >>>>> >> >> We have been discussing multiple issues in this thread. I
>>>>>>> >>>>> >> >> propose
>>>>>>> >>>>> >> >> the
>>>>>>> >>>>> >> >> following strawman (my knowledge of all of the different
>>>>>>> >>>>> >> >> config
>>>>>>> >>>>> >> >> possibilities is limited):
>>>>>>> >>>>> >> >>
>>>>>>> >>>>> >> >> 1) ITK 3.20, should build with gcc4.6. Apparently Debian is
>>>>>>> >>>>> >> >> using
>>>>>>> >>>>> >> >> gcc4.6.
>>>>>>> >>>>> >> >>    We should apply the minimum patches to ITK 3.20 to
>>>>>>> >>>>> >> >> compile
>>>>>>> >>>>> >> >> with
>>>>>>> >>>>> >> >> 4.6. These seem to be a small number of changes.
>>>>>>> >>>>> >> >>
>>>>>>> >>>>> >> >> 2) The specialised patches to ITK 3.20 (e.g. 64 bit support)
>>>>>>> >>>>> >> >> required
>>>>>>> >>>>> >> >> for Slicer3/4 can be delivered via the Slicer3/4 superbuild
>>>>>>> >>>>> >> >> mechanism.
>>>>>>> >>>>> >> >>
>>>>>>> >>>>> >> >> 3) Slicer4 patches to ITKv4 should follow the procedures to
>>>>>>> >>>>> >> >> add
>>>>>>> >>>>> >> >> changes to ITK:
>>>>>>> >>>>> >> >>
>>>>>>> >>>>> >> >>
>>>>>>> >>>>> >> >> http://itk.org/Wiki/ITK_Release_4/New_Code_Contribution_Process .
>>>>>>> >>>>> >> >> The
>>>>>>> >>>>> >> >> goal will be to have Slicer4 build/test with ITKv4.
>>>>>>> >>>>> >> >>
>>>>>>> >>>>> >> >> Slicer is an important ITK customer and the Slicer/ITK
>>>>>>> >>>>> >> >> community has
>>>>>>> >>>>> >> >> large overlap and funding.
>>>>>>> >>>>> >> >>
>>>>>>> >>>>> >> >> Let's refine these topics and come to consensus.
>>>>>>> >>>>> >> >>
>>>>>>> >>>>> >> >> Bill
>>>>>>> >>>>> >> >> _______________________________________________
>>>>>>> >>>>> >> >> slicer-devel mailing list
>>>>>>> >>>>> >> >> slicer-devel at bwh.harvard.edu
>>>>>>> >>>>> >> >>
>>>>>>> >>>>> >> >> http://massmail.spl.harvard.edu/mailman/listinfo/slicer-devel
>>>>>>> >>>>> >> >> To unsubscribe: send email to
>>>>>>> >>>>> >> >> slicer-devel-request at massmail.spl.harvard.edu with
>>>>>>> >>>>> >> >> unsubscribe
>>>>>>> >>>>> >> >> as
>>>>>>> >>>>> >> >> the
>>>>>>> >>>>> >> >> subject
>>>>>>> >>>>> >> >>
>>>>>>> >>>>> >> >
>>>>>>> >>>>> >> >
>>>>>>> >>>>> >> >
>>>>>>> >>>>> >> > --
>>>>>>> >>>>> >> >
>>>>>>> >>>>> >> > ==============================
>>>>>>> >>>>> >> > 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
>>>>>>> >>>>> >> >
>>>>>>> >>>>> >
>>>>>>> >>>>> >
>>>>>>> >>>>
>>>>>>> >>>>
>>>>>>> >>>
>>>>>>> >>
>>>>>>> >
>>>>>>> >
>>>>>>> >
>>>>>>> > --
>>>>>>> >
>>>>>>> > ==============================
>>>>>>> > 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
>>>>>>> >
>>>>>>> _______________________________________________
>>>>>>> slicer-devel mailing list
>>>>>>> slicer-devel at bwh.harvard.edu
>>>>>>> http://massmail.spl.harvard.edu/mailman/listinfo/slicer-devel
>>>>>>> To unsubscribe: send email to
>>>>>>> slicer-devel-request at massmail.spl.harvard.edu with unsubscribe as the
>>>>>>> subject
>>>>>>
>>>>>>
>>>>
>>>
>>
>>
>>
>> --
>>
>> ==============================
>> 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
>>
>



-- 

==============================
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

More information about the Insight-developers mailing list