Hi, On 05/30/2013 12:44 AM, Pete Batard wrote: > On 2013.05.29 12:30, Hans de Goede wrote:
<snip> >> Hmm, so on posix we only care about the libusb-1.0.pc.in file for the >> files you mention. >> That one definitely needs to stay libusb-1.0.pc.in, since we implement >> an extended >> version of the 1.0 API, and apps configure scripts will contain things like >> pkg-config --libs 'libusb-1.0 >= 1.0.15' > > Then I guess I have a follow up question: Under which circumstances > would our libusb-1.[z].pc become libusb-1.[z+1].pc? (NB: this is not > meant as a trick question - I'm genuinely curious about the purpose of > our minor there). Right now, considering everything we discussed, that > minor looks kind of a dead weight to me. It is, yet all libs which strive for parallel installable API incompatible versions (like ie gtk-2 and gtk-3), do it this way. I guess it is reserved for future use mostly. IE when it is decided it is necessary todo a minor API breaking release or some such, I've no clue TBH :) > Not that we want to do anything > about it, but it looks like we would have been equally fine with > libusb-1.pc then. Yep. >> And that should stay working with the 1.2 releases, this is quite >> normal, ie: >> >> [hans@shalem ~]$ rpm -qf /usr/lib64/pkgconfig/gtk+-2.0.pc >> gtk2-devel-2.24.18-1.fc19.x86_64 >> [hans@shalem ~]$ rpm -qf /usr/lib64/libgtk-x11-2.0.so.0 >> gtk2-2.24.18-1.fc19.x86_64 >> >> IOW gtk2 2.24 still provides a gtk+-2.0 pkg-config file and .so files: > > 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 ... > >> If you would prefer for the windows dll to be called libusb-1.2.dll that >> is fine >> with me, although I guess this means adding some conditionals for the >> mingw build. > > I'm still considering our options, but I don't think mixing versions > across platforms is really going to fly. Will most likely add to the > confusion more than anything else. Not sure if that will cause confusion, the soname and real version not being related is normal under Linux, if that is different under Windows, we might consider putting 1.2 in the dll name under Windows. But that is your call. > >> Or we could drop my "all: The next release will be 1.2.0 not 1.0.16" >> commit and >> simply go with 1.0.16. Unless we've some agreement on this beforehand >> I'll drop that >> commit before I push things to libusbx master tomorrow, so that will be >> 1.0.16 for >> now then, and we can always add that commit + fixes later to make it 1.2.0 > > Right now, that's most likely what I'll have to vote for. > Damn, are we condemned to keep 1.0 till the end of time? Nope, only till we add a better poll abstraction, and then also throw in all the other API cleanups we want to do. Regards, Hans ------------------------------------------------------------------------------ Introducing AppDynamics Lite, a free troubleshooting tool for Java/.NET Get 100% visibility into your production application - at no cost. Code-level diagnostics for performance bottlenecks with <2% overhead Download for free and get started troubleshooting in minutes. http://p.sf.net/sfu/appdyn_d2d_ap1 _______________________________________________ libusbx-devel mailing list libusbx-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/libusbx-devel
