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. > On my Debian system I have: > $ ls -l /usr/lib/x86_64-linux-gnu/pkgconfig > total 172 > -rw-r--r-- 1 root root 323 mai 7 09:38 libusb-1.0.pc > -rw-r--r-- 1 root root 207 oct. 2 2012 libusb.pc > Many .pc file do _not_ have a version. # ls -alFh /usr/lib64/pkgconfig/libftdi* -rw-r--r-- 1 root root 252 Mar 30 02:30 /usr/lib64/pkgconfig/libftdi1.pc -rw-r--r-- 1 root root 224 Mar 30 02:30 /usr/lib64/pkgconfig/libftdipp1.pc Just pointing that one (since I'm playing with OpenOCD on Linux, and libFTDI v1.0 from source, through make install, a couple days ago). Is it me or are the libftdi people also doing something they probably shouldn't do then? Likewise, I also have a whole bunch of libftdi1's in my lib64 directory. > 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? > The name of the Windows DLL is another issue. I have no suggestion or > objections. Unfortunately, the "You're free to name the DLL whatever you want on Windows" isn't really gonna fly. We're a cross platform library, so we can't come up with library version numbers that are different across platforms. Otherwise, you'll have someone using both Linux and Windows/MinGW (where pkgconfig is not expected to be available, and was actually a pain to install last time I tried - the MinGW FAQ actually has an entry about this [1]) and crafting their own app build scripts, having to add logic to use -lusb-1.0 on Linux but -lusb-1.2 on Windows (since I don't really see the wrapper for the DLL not following the DLL version, and we have DLL interchangeability with MSVC => we can't count on GNU & libtool having generated the library). > If libusb-1.2 is ABI compatible with libusb-1.0 the library should be > named libusb-1.0.so.0 > > 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. Which pretty much condemns Windows to also use libusb-1.0 for the static and dynamic library, so that cross platform scripts don't have to switch their -l options around. By the way, does one need to use a different option from -lusb-1.0 (if not using pkg-config) when wanting to link against v2.0 so that libusb-1.0.so.1 will be used rather than libusb-1.0.so.0? While I agree that most people on POSIX will probably use pkg-config, I'm still curious to know what is expected to happen if you just use plain old gcc direct linking to build your app. > 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. > 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. > 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. Also: the libftdi people, as well as our past selves, should apparently have known better than introducing explicit versioning in their library name, when bumping the major... ;) Regards, /Pete [1] http://www.mingw.org/wiki/FAQ ------------------------------------------------------------------------------ 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
