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

[Bill Lorensen]

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
>