Add libusb_get_version()

[xiaofan]

Please refer to here.
​http://marc.info/?l=libusb-devel&m=128496751410166

It is quite useful to get the library version.

[pbatard]

implemented in libusb-pbatard (pbr302)

[stuge]

Please make sure to always implement new API functionality and any other distinct feature in a new branch cloned from current libusb.git free from unrelated changes. This is common git practise, in fact the very use it was designed for, and it is quite useful because it allows problems to be resolved as late as possible, which means that changes very rarely, if ever, need to be reworked. If this isn't so clear I'll try to expand on it in a wiki page. Suffice to say that it is an efficient way to manage patches and it allows for low effort (= quick) merging. As an alternative, please attach a patch based on libusb.git to the ticket. Someone will have to make any proposed code apply to libusb.git, and that someone is the person who wants the patch to be applied, typically the author.

Back on topic; I don't think a version number is the good interface here. Applications don't care about numbers but if a particular functionality is available or not. I think an API with the concept of capabilities will be much more useful. This becomes particularly important when considering other implementations of the libusb API, e.g. the one in FreeBSD. Rather than having them manufacture a libusb.org compatible version number I think it makes sense if all libusb implementations use a structured method to inform interested applications about their capabilities.

Here's a simple idea which I think could work well:

#define LIBUSB_VERSION ((LIBUSB_MAJOR&0xff)<<16)|((LIBUSB_MINOR&0xff)<<8)|(LIBUSB_MICRO&0xff)
#define LIBUSB_MAKEVER(major, minor, micro) (((major)&0xff)<<16)|(((minor)&0xff)<<8)|((micro)&0xff)

int LIBUSB_CALL libusb_supports(const char *capability) {
  if(!strcmp(capability, "resetep"))
    return LIBUSB_VERSION >= LIBUSB_MAKEVER(1,0,8);
  if(!strcmp(capability, "hotplug"))
    return LIBUSB_VERSION >= LIBUSB_MAKEVER(1,1,0);
  return 0;
}

[dsd]

I think that having a version check in the library is the wrong thing to do and I don't see a convincing argument in the above link. It can be checked at compile time with pkg-config or the rc info in the windows dll.

The app should check at compile time for the right version, and at runtime for correct resolution of symbols. I suspect that on Windows it could even read from the rc info at runtime.

[xiaofan]

Reopen this ticket as libusb-1.0.9 release reverts the decision.

[xiaofan]

​http://git.libusb.org/?p=libusb.git;a=commit;h=df35117ce58b74fa530baaaccc30adaf432398ea;js=1
Fixed.

[stuge]

In df35117ce58b74fa530baaaccc30adaf432398ea/libusb:

Add libusb_get_version() API function

Let's see how this will be used. Fixes #53.

libusbx.git commit 37dfd16c8c2f36c81c86de303072def0dc405e32

[stuge: Remove unrelated changes]
[stuge: Add struct libusb_version member rc for release candidate suffix]
[stuge: Add struct libusb_version member describe for git describe output]