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

[Stephen Aylward]

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
>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.itk.org/mailman/private/insight-developers/attachments/20110718/7a3901df/attachment-0001.htm>