Re: Cableswig package
Hi Steve,
On Tue, 2006-03-07 at 10:39 -0500, Steve M. Robbins wrote:
> It depends on whether you think waiting to properly package the python
> and tcl bindings will cause undue delay. I'm not sure how much work
> remains in that respect.
Well as it happens, ITK 2.6 was released just 2 days ago! So I'm just
now downloading the latest tarball and will move across the debian build
scripts.
> One thing that I do think is necessary to iron out before any upload
> is the shared library versioning. As you know, I sent an email to itk
> developer's list. I got no response, which likely means it was too
> vague. I will send them a more specific message to propose following
> the VTK model as I outlined previously (where SOVERSION is
> ${major}.${minor}).
Given the implementation is C++, and changing almost anything besides a
comment is likely to break ABI, it is probably safer (no maintenance and
less error-prone) to use the VTK style of making the SOVERSION maj.min.
The ISC is in the process of figuring out a policy of backward
compatability, but ABI is another layer of complexity again. I think a
point release is supposed to preserve ABI, but I doubt a minor release
would.
> OK. I just updated http://people.debian.org/~smr -- it now has gccxml 0.7.0+cvs
> and cableswig 0.1.0+cvs.
Thanks, will snarf those too.
> To answer your question about cableswig version: that comes right out of
> cableswig's CMakeLists.txt:
>
> SET(CableSwig_VERSION_MAJOR 0)
> SET(CableSwig_VERSION_MINOR 1)
> SET(CableSwig_VERSION_PATCH 0)
I believe that's just an oversight. The official number is the tarball,
which is aligned with the ITK release. I guess whoever has been
preparing the tarball just forgot to update the CMake versions. We can
change that in the package and ping Brad/Luis upstream to get it
updated.
:: Gavin
Reply to: