I understand if this will be closed without implementation, but I figured I would ask.
WIth the incompatible changes to the hdhomerun_discover_device_t struct and the new (v2) discover functions, there can be a challenge with shared library versioning on some platforms, and I will note that the make file does not create a versioned library, just a libhdhomerun.so file (and this can lead to the equivalent of "dll hell") if one has both newer and older programs trying to use a shared library. And while there are ways to address these issues, I would like to request that you re-consider providing in the libraries themselves the (now legacy) functions that an old program can continue to access to receive the old discover results, and rename the new structure to something like hdhomerun_discover_device_v2_t for the new functions (yes, this adds work for your existing new internal codes for a one time structure name change). And, for compilers that support such capability, add in the appropriate deprecated attribute on the (now legacy) old functions such that any use will get a warning (to upgrade). The old functions can be provided via the new functions. The intent is to provide some backwards compatibility for a limited period when using a shared (as opposed to internal static) library.
(mostly) untested source diff follows (it compiled on linux!).
Request for enhanced libhdhomerun versioning
I understand if this will be closed without implementation, but I figured I would ask.
WIth the incompatible changes to the hdhomerun_discover_device_t struct and the new (v2) discover functions, there can be a challenge with shared library versioning on some platforms, and I will note that the make file does not create a versioned library, just a libhdhomerun.so file (and this can lead to the equivalent of "dll hell") if one has both newer and older programs trying to use a shared library. And while there are ways to address these issues, I would like to request that you re-consider providing in the libraries themselves the (now legacy) functions that an old program can continue to access to receive the old discover results, and rename the new structure to something like hdhomerun_discover_device_v2_t for the new functions (yes, this adds work for your existing new internal codes for a one time structure name change). And, for compilers that support such capability, add in the appropriate deprecated attribute on the (now legacy) old functions such that any use will get a warning (to upgrade). The old functions can be provided via the new functions. The intent is to provide some backwards compatibility for a limited period when using a shared (as opposed to internal static) library.
(mostly) untested source diff follows (it compiled on linux!).
Thank you for your consideration