On 2013.05.29 12:30, Hans de Goede wrote: > I'm not against dropping sam3u_benchmark the only reason I added it is: > "sync everything which looks like it may be > useful from libusb git to libusbx git" > > So I see 2 ways forward keep it and try to make it more portable one of > these days, or at a git commit reverting it > explaining why we've decided to not keep it. I do believe having a > commit adding it + revert is the right thing > to do wrt trying to merge the 2 gits back into one and keeping as much > history as possible.
I'm just indicating my preference at this stage, but since I'm not really planning to spend time on making sam3u Windows compatible in the near future, I'll leave the decision on whether to include it or not on yourself and anybody else who wants to chime in on that. > 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. Not that we want to do anything about it, but it looks like we would have been equally fine with libusb-1.pc then. > 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? > 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. > 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? >> Btw, when did we add topology to listdevs? That looks real neat! > > I did that while testing Nathan's hotplug + topology fixes, so as to > have something which actually used the topology stuff: To be fair, xusb has been using the topology calls since day one, but I eventually moved them behind the -i (display additional device info) option. If the ridiculously slim listdevs can be fattened with this kind of generic ode, I think I'm gonna trim down xusb, and remove the topology calls there. Regards, /Pete ------------------------------------------------------------------------------ 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
