search

enzo1982 / BoCA

A component library used by the fre:ac audio converter
https://www.freac.org/
GNU General Public License v2.0
36 stars 9 forks source link

Bug: REVISION variable not up to date in runtime/Makefile #8

Open Janosch opened 3 years ago

Janosch commented 3 years ago

In https://github.com/enzo1982/BoCA/blob/master/runtime/Makefile the Revision is set to 2 although the release 1.0.3 has already been shipped.

I am currently working on packaging freac for macports, this is why I stumbled over this. I can workaround this issue by overwriting REVISION but macports always advises to fix things upstream, eleminating the need for workarounds in the packaging system.

I think it needs to be set to 4 on master, assuming the next release will be 1.0.4.

Btw, do you prefer pull requests for issues like this or is creating an issue ok too?

enzo1982 commented 3 years ago

Thank you for packaging BoCA for macports.

The REVISION number in the Makefile does not correspond to the micro version number of BoCA releases. Instead, it's the compatibility level of the output library (what's called soversion in other build systems).

The revision was set to 2 for BoCA 1.0 beta 1, because some API changes had been introduced with that release. Since then, all further releases should be source and binary compatible, so the compatibility level was left untouched.

Janosch commented 3 years ago

Ok, thanks for clarifying. I had to read up some things to learn about library versioning to understand your reasoning. The apple docs about dynamic linking were especially helpful.

I just wanted to make you aware of the fact that with Clang, the REVISION can be set with the command line option _-compatibilityversion and the minor version can be set with _-currentversion. So instead of writing the major, minor and compatibility version into the library ID, like it is done at the moment:

libsmooth-0.9.0.dylib (compatibility version 0.0.0, current version 0.0.0)

using the flags it could look like this:

libsmooth.0.dylib (compatibility version 9.0.0, current version 9.6.0)

Maybe I am telling you things you allready know. I think using the clang flags would be more "Mac-ish" but I can totally understand if you dont want to include every mac-specific feature in your Makefiles. If you think it is worth adapting the Makefiles I can prepare a pull request.