Hi, On 09/15/2012 03:41 AM, Pete Batard wrote: > I have now pushed the bMaxPower change to mainline. Before I go 1.0.13-rc1 > however, I think I'm warming up to the idea of having a macro in libusb.h, > that could be used to uniquely identify API changes. > > Basically, I'm thinking of something like: > > #define LIBUSBX_API_VERSION 0x01001234 > > where the first 16 bits would be the major & minor expressed as bytes > (unlikely to require > 256 values and major/minor version changes should be > be linked to an API change), and the lower 16 bits a value that would be > increased every time we commit new changes to the API, eg. when we add a new > call, such as libusb_get_version, or a new enum value, such as > LIBUSB_SET_ISOCH_DELAY, or even if exceptionally decide to alter an existing > property. > > Now, this would of course require manual handling (unless we decide to do > something similar to the handling of the version nano and increase > LIBUSBX_API_VERSION on each commit regardless, which we could, as I doubt > we'll get a distance to root on mainline that's ever going to be > 65535 > without changing the minor, and this whole thing is really versioning in > disguise anyway), but I think it could help provide some avenue for our users > to: > > 1) Check if they're using libusbx or libusb on the system (#ifdef > LIBUSBX_API_VERSION - we'll leave nothing or LIBUSB_API_VERSION to libusb) > > 2a) Check if an API call or value is supposed to be available at compilation > time and 2b) Simplify our user's conundrum with bMaxPower: > > #if defined(LIBUSBX_API_VERSION) && (LIBUSBX_API_VERSION >= 0x01000100) > dev->config[0].bMaxPower < 250 > #else > dev->config[0].MaxPower < 250 > #endif > > I believe this is close to what Toby wanted to see us provide.
Not sure if we really need the last 4 bytes, just major and minor, + documenting API changes when they happen in News should be enough, and I don't feel the last 4 bytes add much value, other then that this looks good! > > Otherwise, for the bMaxPower update, my current preferred proposal would be > to have user copy/paste the new libusbx descriptor structure as is, use that > in their app exclusively and then use a cast. I'm strongly against suggesting our users to do something like that, instead lets just give them a version define to check against. Regards, Hans ------------------------------------------------------------------------------ How fast is your code? 3 out of 4 devs don\\\'t know how their code performs in production. Find out how slow your code is with AppDynamics Lite. http://ad.doubleclick.net/clk;262219672;13503038;z? http://info.appdynamics.com/FreeJavaPerformanceDownload.html _______________________________________________ libusbx-devel mailing list libusbx-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/libusbx-devel
