Hi, On 06/01/2013 01:09 AM, Pete Batard wrote: > On 2013.05.31 08:57, Ludovic Rousseau wrote: >> Another proposal is to remove the version number from the .pc file. > > Well, it sure looks like dead weight to me.
Erm, no, see below. <snip> >> The filename libusb.pc is already used by libusb-0.1. So we can't use >> that without conflicts. > > OK, so we can't actually remove the version. > Does that mean that, while the API/ABI compatibility problem has been > solved at the library level on POSIX, it still hasn't been solved at the > pkgconfig level? > > You mentioned one can use PKG_CHECK_MODULES(LIBUSB, libusb-1.0 >= > 1.0.15, ...). Is there anything along these lines that would allow the > use of a single libusb.pc to pick 0.1, 1.0, etc? No, but the idea is that you check for the API version your app is programmed for. So app programmed for libusb-0.1 check for 'libusb >= 0.1.x', where as apps programmed for libusb-1.0 check for ie 'libusb-1.0 >= 1.0.15', and apps programmed for libusb-2.0 when released would check for 'libusb-2.0 >= 2.0', etc. This assumes that an app is programmed to work with a specific API versions, if it can work with say both libusb-1.0 and libusb-2.0 it needs to explicitly check for its configure script (or equivalent). <snip> >> libusb-2.0 will break the ABI and will be named libusb-1.0.so.1 >> Note that we do not have a "2.0" anywhere in the file name. Erm, no not necessarily since we have the API version nr in the soname, we could and should name it libusb-2.0.so.x >> On POSIX the library name do not reflect the library version. >> The packaging system (dpkg, rpm, etc.) will tell you what version of >> the library is installed. > > Considering that the above is dependent on having installed the library > using a distro's specific pkg system, I think using the "pkg-config > --modversion" you pointed out earlier is probably safer and more universal. Right, and that is what allmost all configure scripts will do. > >> The problem origin is that the library _name_ on POSIX is libusb-1.0. >> This comes from the line in Makefile.am >> lib_LTLIBRARIES = libusb-1.0.la >> >> A library name do not include any version information. So the "-1.0" >> in the name is not part of the library version but part of the library >> name. And we can't change the library name, unless we want to provide >> a completely different library. > > Which I would wager people, such as the libfti guys, as well as > ourselves, seem to have decided to ignore in the past when we felt it > would be more intuitive for users this way. > > IMO, it's not because POSIX can solve the problem of library versioning > on its own that it means the use of complementary/redundant versioning > methods needs to be banned. > Some people still seem to prefer relying on a more apparent versioning. > If that can help avoid user-confusion, I can't really fault that logic. What can be done is out the version in the file name of the library while leaving the soname (which is metadata inside the file) the same, ldconfig will then create a symlink with the soname as filename to the name under which the library was installed. > >> To summarise: >> For libusb-1.2 >> - do not change the libusb-1.0.pc name >> - do not change the libusb-1.0.so, libusb-1.0.so.0 names >> - do whatever you want on Windows >> - the library name should have been libusb instead of libusb-1.0. But >> it is too late to fix that. > > Well, the way I'd summarize it is: > We are stuck with the libusb-1.0 name, for ever, across all platforms. For our 1.0 API + ABI compatible versions, for the .so and .pc filenames, yes. We could still call it version 1.2, there are plenty of examples of projects doing the same, freezing the filenames at minor 0, while still bumping the minor. Note either 1.0.16 or 1.2.0 works for me, lets just make a decision, then I code up my new strerror proper, and we do a rc0 release. Regards, Hans ------------------------------------------------------------------------------ Get 100% visibility into Java/.NET code with AppDynamics Lite It's a free troubleshooting tool designed for production Get down to code-level detail for bottlenecks, with <2% overhead. Download for free and get started troubleshooting in minutes. http://p.sf.net/sfu/appdyn_d2d_ap2 _______________________________________________ libusbx-devel mailing list libusbx-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/libusbx-devel
