On 2012.08.06 09:39, Toby Gray wrote:
> All your comments seem sensible. I'm happy to make the suggested changes
> myself.
>
> I'm a bit busy at the moment so it'll be towards the end of this week or
> the start of next week that I'll get time to do this though.
That's fine. We got plenty to keep us busy outside of CE integration ;)
Also, I won't have a problem going through integration and leaving any
of the minor points for later.
> I think it still makes sense for CEUSBKWrapper. As CEUSBKWrapper builds
> within platform builder rather than visual studios, it's not a simple
> task to reference the .lib and header files from a CEUSBKWrapper build
> into the libusb project.
OK.
>> - I would very much like to have the xusb sample compiled in the
>> project. Currently only listdevs is. The rationale is that xusb can be
>> quite useful when trying to troubleshoot issues...
>
> I agree. The reason xusb was missed is that we originally based the
> WinCE backend on libusb 1.0.8 and forgot to add build files for xusb
> when switching to basing the backend onto libusbx.
Thanks.
> It's simple enough to add building as a static lib and it might help
> someone so I'm happy to do this.
I think the switching between .lib and .dll should be simple enough for
people wanting the static lib. For what is worth, I'd be fine with
waiting to see if there is demand for the static lib on CE before adding
a static lib option.
>> - The Windows solution file places the built libraries and executables
>> into a /Win32 or /x64 a the top level, whereas CE places those into
>> /wince/STANDARDSDK_500 (ARMV4I). For the sake of consistency, we
>> probably want to have the CE build directory at top level.
>
> This has been annoying me a bit as well. Are you happy with keeping the
> "STANDARDSDK_500 (ARMV4I)" name or would you prefer something a bit more
> obviously WinCE based such as "WinCE/STANDARDSDK_500 (ARMV4I)"?
Personally, I find the naming choice of Microsoft very disputable here
("STANDARDSDK"? Yeah, that sure provides super useful information...)
and it seems Microsoft can't stick to a naming convention anyway (For
instance, in latest WinUSB redistributables [1] MS replaced "amd64" for
"x64" for the x86_64 binaries), so we might as well go with something
better. I'll also probably propose a change to relabel the Win32 target
to x86 when we integrate CE, as this is what Microsoft seems to have
picked for VS2012 and elsewhere and most likely what our users will come
to expect.
Thus, eventually, I'd like to have an x86/, x64/ or ARM/ (all caps)
target in the libusb root for the MSVC targets, with both CE and Windows
RT ending up in ARM. Of course that's just my personal preference.
> I like the idea of /msvc_wince.
OK.
Regards,
/Pete
[1] http://msdn.microsoft.com/en-US/windows/hardware/br259104
------------------------------------------------------------------------------
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
