libusb icon indicating copy to clipboard operation
libusb copied to clipboard

Allow configure-time version detection of libusb

Open mbr0wn opened this issue 4 years ago • 4 comments

I would like to request a way of having the actual version of libusb available without executing it (i.e., without calling libusb_get_version()). The simplest way to do this would be to make version.h public (probably needs some sprucing up) as libusb_version.h, or something like that.

Rationale

When detecting libusb versions during configuration time (i.e., when running autoconf or cmake), it is often useful to know the version of libusb. For example, you might want to require a certain minimum version of libusb. One solution can be to create a mini-C-file, compile and execute it as part of the configuration script, and read the output. But that is not always a satisfactory solution: For example, when doing cross-compiles, you might not always have a binary of libusb in your native arch available.

Very useful would be the ability to simply read the version from somewhere like the header file. This way, your configuration tool (cmake or autoconf) could simply parse that.

LIBUSB_API_VERSION is also not a satisfactory alternative. While it is super useful in the context of deciding which API to call using preprocessor macros, it is really awkward to require the user have a version of libusb with a certain API version available (since they don't match). And of course, it only changes with API changes. So if I want a specific version because it also contains a bugfix, it's not the right tool either.

mbr0wn avatar Aug 25 '21 14:08 mbr0wn

Maybe you can use the --atleast-version= argument of pkg-config? Something like (I have libusb version 1.0.24 installed):

$ pkg-config --atleast-version=1.0.24 libusb-1.0 && echo "OK"
OK

Checking for version 1.0.25 fails:

$ pkg-config --atleast-version=1.0.25 libusb-1.0 || echo "KO"
KO

If you use a configure.ac script it is easy to use PKG_CHECK_MODULES([LIBUSB], [libusb-1.0 >= 1.0.24]). See https://autotools.io/pkgconfig/pkg_check_modules.html#pkgconfig.pkg_check_modules.specification

LudovicRousseau avatar Aug 25 '21 15:08 LudovicRousseau

Huh, I must have fat-fingered by pkg-config because I thought that was not working. Thanks for that feedback.

Not all archs have pkg-config available, though. If you want the same build configuration script for Mac/Linux/Windows, then you can't rely on it. In general, I use pkg-config whenever I can (even if the version is stored somewhere else, too), but if I do start checking dependency versions, I need a fallback method for the numerous cases where pkg-config is not available.

mbr0wn avatar Aug 25 '21 15:08 mbr0wn

The simplest way to do this would be to make version.h public (probably needs some sprucing up) as libusb_version.h, or something like that.

Just wondering which project provides this kind of thing.

mcuee avatar Aug 26 '21 02:08 mcuee

It's pretty common. Here's some dependencies I deal with:

  • Boost (has BOOST_VERSION)
  • DPDK (has rte_version.h)
  • Python (has PY_*_VERSION and PY_VERSION from patchlevel.h)

Boost is a good example, because it's so ubiquitous, and yet so difficult to properly identify. Only recently did Kitware and Boost team up to get a good CMake integration for finding Boost: https://github.com/Kitware/CMake/blob/cb7edb1f4b46c391c9190ee24b850346dff2d83f/Modules/FindBoost.cmake#L1787-L1801

...and lo and behold, they, too, scrape the headers for the version. Same for DPDK; we can't rely on pkg-config, so we try it first, then, scrape headers: https://github.com/EttusResearch/uhd/blob/master/host/cmake/Modules/FindDPDK.cmake

mbr0wn avatar Aug 26 '21 08:08 mbr0wn