[MINC-users] MINC 2.0.13

[Steve M. Robbins]

On Fri, Oct 05, 2007 at 12:51:23PM +1000, Andrew Janke wrote:
> I wrote:
>
> > That's good news.  I'd like to package this version for Debian, either
> > alongside the current Debian minc package (version 1.5) or replacing
> > it.
> > The library versioning, however, remains a problem.  Packagers such as
> > Debian prefer to ship shared libraries.  For this to work
> > successfully, the software must correctly version the shared libraries.
> > Since you're using libtool, you need only follow the rules outlined
> > in http://www.gnu.org/software/libtool/manual.html#Versioning,
> > specifically section 6.3.
> >
> > It would be helpful if the MINC maintainers would commit to following
> > this procedure.  Is this possible?
> 
> Possible, although I suspect the more deep-seated problem is that minc
> really needs to be split into libminc and minc-tools within CVS to
> make life easier I guess?

Nope; that's not an issue at all.


> I had thought that we were following libtool style versioning though?
> (from what I can read of that page you mention) or am I missing
> something? (likely).

It's not enough to follow "libtool style" of versioning.  You must
follow the entire procedure.  For each release, the releaser must look
at the changes and decide whether any public interfaces have been
added, removed, or changed.

Even if nothing has changed, the REVISION must be incremented.  I note
that this was not done from 2.0.13 --> 2.0.14, for example.  In fact,
CVS shows the following history:

6.1          (stever   08-Jan-03): libminc_la_LDFLAGS = -version-info 0:0:0
6.11         (stever   14-Nov-03): libminc_la_LDFLAGS = -version-info 1:0:1
6.12         (bert     27-Apr-04): libminc2_la_LDFLAGS = -version-info 2:0:1
6.27         (claude   19-Apr-06): libminc2_la_LDFLAGS = -version-info 2:0:10
6.28         (claude   19-Apr-06): libminc2_la_LDFLAGS = -version-info 2:0:1

So one is forced to conclude that MINC2 is not properly versioned,
since it has gone through something like 14 releases.


> The other note of contention is that I presume you will be building
> shared versions of libminc whereas typically in the past everything
> has been static.

Debian's MINC has always built shared libraries.  They are, however,
installed in /usr/lib, so the standard argument against shared libs
does not apply.


> Then to add another cat into the mix I have been working on a CMake
> (shudder) build of MINC for the ITK integration stuff and suffice to
> say I have found no easy way to sync the two build processes. :(  It's
> hard enough to find any documentation on CMake out there without
> buying the book as it is so getting the thing to behave as I expect
> has proved problematic (make install,dist,distcheck etc).
> 
> Do you have any thoughts on CMake steve?  All those who use it seem to
> crow its praises over autoconf/make but from what I have seen of it so
> far it is easy(ish) to use but the lack of documentation and worked
> examples of how things should be done is slowing me up a lot.

We use CMake at work.  It's main selling feature is that it can
produce MSVC project files as easily as Makefiles, whereas autoconf
heavily depends on having the unix suite of commandline tools.

Myself, I haven't written CMake rules for "install", let alone "dist"
and the like.  I'd imagine that ITK itself should supply enough of an
example to get you going.  Good luck.


Cheers,
-Steve