Re: [fluid-dev] compatibility version problem

[Pedro Lopez-Cabanillas]

On Thursday 30 September 2010, Ebrahim Mayat wrote:
> Hello again
> 
> In the transition from autotools to cmake on OS X, I came across  
> version number compatibility issue for the libfluidsynth shared  
> library..

The new CMake build system is not an exact copy of the autotools. That is not 
the goal. There is not a 1:1 relationship of functions. 

In the future, both build system will diverge even more, and at one point the 
old build system will be removed completely. I plan to improve the CMake build 
system, including features that are exclusive of Mac OSX, like for instance 
creating a relocatable library framework bundle.

> The names and version numbers of libfluidsynth are:
> 
> 1. using autotools for the previous version of fluidsynth-1.1.1
> 
> /sw/lib/libfluidsynth.1.dylib (compatibility version 5.0.0, current  
> version 5.0.0)
> 
> 2. autotools with fluidsynth-1.1.2 gives
> 
> /sw/lib/libfluidsynth.1.dylib (compatibility version 6.0.0, current   
> version 6.0.0)

The autotools build system uses libtool, and these funny numbers are a 
consequence of the libtool numbering scheme. The numbers are absurd, BTW. What 
means the current version number "6.0.0"?

CMake doesn't follow the same version numbering scheme, which is a good thing, 
IMO. In Linux (unlike Mac OSX) libtool creates the shared library with a 
reasonable version number, so the CMake build system tries to use the same 
(resulting) number, and the packagers can do the switch of build systems 
without concerns. Lucky them!

> 3. while building with cmake for fluidsynth-1.1.2 gives
> 
> /sw/lib/libfluidsynth.1.dylib (compatibility version 1.0.0, current  
> version 1.4.0)

Which is correct for me, and matches the library version of the Linux shared 
library. It clearly reflects the purpose of the library version numbering: the 
"current version" value is the last one, and the compatibility level is also  
a real one. 

I can predict that the next package FluidSynth-1.1.3 using CMake is going to 
contain a library version "1.4.1", with his oldest compatible interface 
version "1.0.0".

> The problem arises due to the fact that updating from 1.1.1 to 1.1.2,  
> there is a concomitant downgrade of compatibility version from 5.0.0  
> to 1.0.0.
> This downgrade can break all programs that link to the previous  
> version of libfluidsynth resulting in distribution breakage.

Then, you shouldn't allow to upgrade packages created with both build systems. 
This is a packaging problem. One solution may be to add an "epoch" number, 
like Debian does sometimes, to the package created using the CMake build 
system.

> Two possible solutions could be:
> 
> 1. Revert to autotools so that the compatibility version also upgrades  
> (from 5.0.0 to 6.0.0).

That is your decision, of course. But, what are you going to do when we remove 
the old build system?

> 2. Force cmake to increase the compatibility version. (I don't know  
> how I would do this but there is probably a way ? )

src/CMakeLists.txt, line 222, macro set_target_properties()
You can play with the attributes "VERSION" and "SOVERSION", but I strongly 
advice against that. You are not going to obtain exactly the same result.

Regards,
Pedro