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

[Bill Lorensen]

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