On Thu, 28 Jul 2022, at 17:06, Robin Gareus wrote: > On 7/28/22 15:52, Chris Cannam wrote: >> >> The version in the .pc file is written in at install time, > > Except, it isn't. $PREFIX/lib/pkgconfig/rubberband.pc here has Version: > 1.8.2 for rubberband v3.0.0
Oops. How are you installing? If I use e.g. "meson build && ninja -C build && ninja -C build install" here I get a copy that does have the right version in it. I haven't looked too closely at how it does that though. Since it appears to work equally well with %VERSION% in the .in file, and it's obviously not great to have a wrong literal value in there, I'll make that change. >> The ABI has been at 2.something since version 1.2, > > Yeah that's fine. I was just surprised to see the age being zero. > > http://www.gnu.org/software/libtool/manual/html_node/Updating-version-info.html That page just makes my head spin a little faster if anything! It seems rather libtool-specific and doesn't indicate how current:revision:age maps on to the installed library suffix. Is "current" the soname number, "revision" the minor number, and "age" the point number, as I would naively read it? If so, then it appears to be saying that merely adding a function *should* result in incrementing the soname: "If any interfaces have been added, removed, or changed since the last update, increment current, and set revision to 0" where "current" is the soname, right? As I read it, it seems to be saying that if the current version is (say) 2.1.7, then a backward-compatible addition should result in an updated version 3.0.8 whereas an incompatible change should result in 3.0.0. I'm not sure I understand the logic regardless of the explanation in the page. I don't recall having ever read quite that method before. Chris _______________________________________________ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org https://lists.linuxaudio.org/listinfo/linux-audio-dev
