-
Notifications
You must be signed in to change notification settings - Fork 9
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Bug: REVISION variable not up to date in runtime/Makefile #8
Comments
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. |
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 -compatibility_version and the minor version can be set with -current_version. So instead of writing the major, minor and compatibility version into the library ID, like it is done at the moment:
using the flags it could look like this:
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. |
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?
The text was updated successfully, but these errors were encountered: