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 _______________________________________________ fluid-dev mailing list [email protected] http://lists.nongnu.org/mailman/listinfo/fluid-dev
