Re: [LAU] [FFADO-devel] [ANN] FFADO 2.0 Release Candidate 1 (1.999.40) available

The traditional way is to use libtool version numbers. The idea is to give the library a three-part number reflecting: (a) the current interface version; (b) minor compatible updates to that version; and (c) an indication of how many previous versions are also supported. It's basically a binary compatibility scheme. The loader can compare the library version with that used by a program linking to it. If the versions are compatible, then that library should work. The idea is simple, but the details are quite messy and confusing... http://www.nondot.org/sabre/Mirrored/libtool-2.1a/libtool_6.html http://www.ensta.fr/~diam/dev/online/autoconf/autobook/autobook_91.html There is native support for all that in the automake, autoconf toolset, which leaves the question of how to do similar stuff in SCons. I am just beginning to use SCons on another project, and coincidentally I wanted to do libtool versioning for it only last week. I was unable to come up with a quick solution. The native SCons SharedLibrary() method does not obviously support it. I didn't spend much time researching the matter, however. SCons is a good tool, and is becoming popular. Surely many people have already solved this problem by now.