Skip to content
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

Open
Janosch opened this issue Dec 27, 2020 · 2 comments
Open

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

Janosch opened this issue Dec 27, 2020 · 2 comments

Comments

@Janosch
Copy link

Janosch commented Dec 27, 2020

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?

@Janosch Janosch changed the title REVISION variable not up to date in runtime/Makefile Bug: REVISION variable not up to date in runtime/Makefile Dec 27, 2020
@enzo1982
Copy link
Owner

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
Copy link
Author

Janosch commented Dec 27, 2020

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:

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants