Firstly I apologise for sending my message body as HTML, I've clearly not figured out how to force Thunderbird to always send as plain text.
On 12/07/12 20:59, Pete Batard wrote: >>> 0004 - Replaces getenv() with NULL on WinCE due to it not being supported. >> Try to change this in a good way where getenv() is called, instead. >> Is there an equivalent to environment variables in Windows CE? Maybe >> the registry? The question is in which key the value would be. > I'd also prefer if we could have something better than a null getenv(), > provided that it's possible. But whether this is being looked at > tomorrow or months from now isn't a major concern. > >> If no, then you can always simply make autoconf check for getenv and >> put the code in libusb_init() within #ifdef HAVE_GETENV. Just don't >> forget to initialize the dbg stack variable if you go that route. > That would indeed be the better approach. Again, Toby, whether you want > to do that now or later on is not an issue, as, unlike libusb, we're > trying to be RERO, so we'll prefer early integration of a new > experimental backend over added delays due to minor implementation > details that can be improved later. I'm happy to try to sort this out now with a registry setting. It's been annoying me a bit when debugging the library that I can't turn on the debugging output without recompiling either libusbx or the code calling into it. I've put an alternative fix into the branch which I plan to keep rebased on libusbx/master: https://github.com/tobygray/libusbx/commit/4b0f2413ae85d197db8721e2fda5a85355d95e1b The only thing I'm not sure of in this fix is that wince_usb.c doesn't seem like it's quite the right place for it. What do you think? > > ------------------------------------------------------------------------- > > OK, now with regards to what I would have been replying outside of > Peter's intervention: > > 1. This is great. The more backends we have, the better! > > 2. Obviously, we'll want to flag this backend as experimental for a > while after we integrated these changes. But because it'll be > experimental, we should be able to get some leeway with regards to the > process. I'm hoping we can have some of it in 1.0.13. If not, 1.0.14 > should definitely be our target. That's sounds like a good plan to me. > 3. My preference for having this integrated would be that: > - you create a fork for it on github, based on > https://github.com/libusbx/libusbx, which is where we have moved our git > master. The idea is that, if it does take a while before we start > looking at CE integration, you'll be able to rebase your patches against > the latest libusbx for when we are ready, and people who follow libusbx > and want to play with your changes will be able to use the same > infrastructure. I did almost submit the patches this way. I only avoided it as I wasn't sure if it'd be the desirable way. I've created a repository with a WinCE branch here: https://github.com/tobygray/libusbx I've left the original branch that I created there as wince_original as I've noticed that you've referenced the handle leak fix in the windows code already. I was planning on sending it as a separate patch, but I'll just keep the wince_original branch until you've integrated the fix. > Also, when you have a fork, you can directly attach > patches from your fork to issues raised against the origin. > - you create a new enhancement for adding CE support at > https://github.com/libusbx/libusbx/issues, so that it's firmly on our > agenda, and so that it's publicized. Done: https://github.com/libusbx/libusbx/issues/35 I see you've already commented on it as I got distracted by fixing the getenv implementation before clicking send on this email. > > Now, it seems in his eagerness to impose his mark on this integration > process, Peter has rushed into commenting on your code. I'm not going to > do the same, as I'd prefer reviewing what you've sent at my leisure. That's fine. I've got plenty of other things that need doing to keep me busy :) Regards, Toby ------------------------------------------------------------------------------ Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ _______________________________________________ libusbx-devel mailing list libusbx-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/libusbx-devel
