Distributing Fmod with a wrapper library

[Sunkin351]

Continuing the discussion from Nugget Package for FMOD low level binaries:

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:

@sodanakin

I think if a disclaimer were to be added to the Nuget package / Github Repository regarding which version of Fmod the end user is dealing with and that Fmod is not responsible for any bugs, broken features etc, no extra support nor updating should be required as this is fully up to Sunkin to manage the repo and Update the dll with new releases.

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.

[brett]

@Sunkin351

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.

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.

[Sunkin351]

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?

[brett]

@Sunkin351

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.

[Sunkin351]

I’m switching up my loading scheme to be backwards compatible then, while still exposing new functions. Thanks for the replies!