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.…
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