2013/5/30 Pete Batard <p...@akeo.ie>: > On 2013.05.30 10:12, Hans de Goede wrote: >>> Still makes me curious. Do you know of any project where a >>> major.nonzero-minor.pc is used? >> >> ls /usr/lib64/pkgconfig shows 1 on my system: >> >> lrwxrwxrwx. 1 root root 17 Apr 5 15:48 soundtouch-1.0.pc -> >> soundtouch-1.4.pc >> -rw-r--r--. 1 root root 315 Feb 18 11:18 soundtouch-1.4.pc >> >> And notice how there is a symlink to work around the issues this causes ... > > I also notice the suspension marks, as if you're waiting for a follow > up. So here goes: > > Doesn't that mean that we could do something like go 1.2 everywhere and > symlink the heck of required 1.0 refs to 1.2 ones? Might also help > people like Sean, who don't really want the extra functionality that > 1.2/1.0.16 will thrust upon them, though they'd probably have to > maintain their own version of 1.0 then.
Another proposal is to remove the version number from the .pc file. The .pc file contains the library version and that version can be queried using: $ pkg-config --modversion libusb-1.0 1.0.15 or using PKG_CHECK_MODULES(LIBUSB, libusb-1.0 >= 1.0.15, ...) in configure.ac So the name of the .pc file should _not_ change over the different versions. On my Debian system I have: $ ls -l /usr/lib/x86_64-linux-gnu/pkgconfig total 172 -rw-r--r-- 1 root root 264 mars 13 22:18 dri.pc -rw-r--r-- 1 root root 264 mars 13 22:18 gl.pc -rw-r--r-- 1 root root 258 mars 13 22:18 glu.pc -rw-r--r-- 1 root root 275 mars 18 20:44 libcrypto.pc -rw-r--r-- 1 root root 211 oct. 12 2011 libffi.pc -rw-r--r-- 1 root root 283 mai 28 10:11 libpcsclite.pc -rw-r--r-- 1 root root 349 nov. 18 2011 libsqueeze-0.2.pc -rw-r--r-- 1 root root 290 mars 18 20:44 libssl.pc -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 -rw-r--r-- 1 root root 430 juil. 17 2012 libxfce4sensors-1.0.pc -rw-r--r-- 1 root root 300 mars 18 20:44 openssl.pc -rw-r--r-- 1 root root 181 nov. 11 2011 pthread-stubs.pc -rw-r--r-- 1 root root 1169 févr. 5 23:28 Qt3Support.pc -rw-r--r-- 1 root root 1075 févr. 5 23:28 QtCLucene.pc -rw-r--r-- 1 root root 1087 févr. 5 23:28 QtCore.pc -rw-r--r-- 1 root root 1099 févr. 5 23:28 QtDBus.pc -rw-r--r-- 1 root root 1182 févr. 5 23:28 QtDeclarative.pc -rw-r--r-- 1 root root 1038 févr. 5 23:28 QtDesignerComponents.pc -rw-r--r-- 1 root root 917 févr. 5 23:28 QtDesigner.pc -rw-r--r-- 1 root root 1269 févr. 5 23:28 QtGui.pc -rw-r--r-- 1 root root 1146 févr. 5 23:28 QtHelp.pc -rw-r--r-- 1 root root 1077 févr. 5 23:28 QtNetwork.pc -rw-r--r-- 1 root root 1218 févr. 5 23:28 QtOpenGL.pc -rw-r--r-- 1 root root 1098 févr. 5 23:28 QtScript.pc -rw-r--r-- 1 root root 1143 févr. 5 23:28 QtScriptTools.pc -rw-r--r-- 1 root root 1058 févr. 5 23:28 QtSql.pc -rw-r--r-- 1 root root 1094 févr. 5 23:28 QtSvg.pc -rw-r--r-- 1 root root 1054 févr. 5 23:28 QtTest.pc -rw-r--r-- 1 root root 871 févr. 5 23:28 QtUiTools.pc -rw-r--r-- 1 root root 1069 nov. 18 2012 QtWebKit.pc -rw-r--r-- 1 root root 1112 févr. 5 23:28 QtXmlPatterns.pc -rw-r--r-- 1 root root 1058 févr. 5 23:28 QtXml.pc -rw-r--r-- 1 root root 302 juin 16 2012 x11.pc -rw-r--r-- 1 root root 244 avril 9 2012 xau.pc -rw-r--r-- 1 root root 299 oct. 15 2012 xcb.pc -rw-r--r-- 1 root root 252 avril 14 2012 xdmcp.pc -rw-r--r-- 1 root root 257 avril 15 2012 xext.pc -rw-r--r-- 1 root root 285 nov. 8 2012 xfce4-session-2.0.pc -rw-r--r-- 1 root root 329 janv. 23 2012 xfprint-1.0.pc -rw-r--r-- 1 root root 260 mai 20 2012 xi.pc -rw-r--r-- 1 root root 256 avril 23 2012 xtst.pc -rw-r--r-- 1 root root 264 juin 22 2012 zlib.pc Many .pc file do _not_ have a version. The filename libusb.pc is already used by libusb-0.1. So we can't use that without conflicts. We can create a libusb-1.2.pc or a libusb-2.0.pc with a symbolic link libusb-1.0.pc But I don't know if many projects will use the new names. They may just use: PKG_CHECK_MODULES(LIBUSB, libusb-1.0 >= 2.0, ...) The name of the Windows DLL is another issue. I have no suggestion or objections. > If we don't override 1.0, in case it already exists on the system (or, > more realistically, since we will prefer users to override their > existing 1.0 with 1.2, give them a choice not to override existing if > they think they have a good reason not to), it'd allow separate 1.0 and > 1.2 to coexist, and we'd also have people transparently using 1.2 as if > it was 1.0 in most cases. It is a different question. The .pc file is used at build time. 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. > Now, there might be pkgconfig & standard POSIX lib folder subtleties > that mean it's not that simple, and it could also mean never being quite > sure whether a 1.0 user is actually using 1.2 or an old 1.0, but seeing > the symlinking of soundtouch-1.4, I'm not sure I want to let go the idea > of going 1.2 just yet... 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. $ COLUMNS=120 dpkg -l libusb-1.0-0 ||/ Name Version Architecture Description +++-========================-=================-=================-===================================================== ii libusb-1.0-0:amd64 2:1.0.11-1 amd64 userspace USB programming library Here the version is 1.0.11 (the libusb version in Debian stable released in May 2013). The /usr/share/doc/libusb-1.0-0/copyright indicates it comes from http://www.libusbx.org See http://ftp-master.metadata.debian.org/changelogs//main/libu/libusbx/libusbx_1.0.11-1_copyright 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. 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. Hope this helps. -- Dr. Ludovic Rousseau ------------------------------------------------------------------------------ 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
