Sodanakin sums up my need pretty nicely. Its a bit of a hassle if Fmod API changes that are reflected in a wrapper library break because the user has an outdated version of the Fmod binary.
I would like to distribute the Core API binary with the wrapper. This would simplify the situation of the end user and create a much more hassle free experience.
To quote sodanakin:
I was wondering what I would need to do in order to get your guys’ approval on this. The wrapper itself is free and open source for anyone to use.
This will never happen if the version used sticks to the major version number, as well as the users. An example is 2.01.xx (all xx changes are forwards and backwards compatible).
For the larger overall topic we are still deliberating, we not keen on unofficial distribution of the API for liability purposes. FMOD is not just a header and a binary, it is support, documentation, examples and more.
The biggest problem is that I’m not currently lazily loading symbols from the library here. This Causes it to not quite be able to target previous versions with ABI differences.
Also, another matter. Why is Fmod version checking tied to having an instance of FMOD_System up and running? Shouldn’t version checking helpers be static methods?
There are no ABI differences in a major version with all of its minor versions.
For static vs dynamic, it is theoretically possible that different versions of the library can coexist, ie through dynamic loading of the dll. This is more historical than anything else.