On 05/08/12 23:24, Pete Batard wrote: > Finally got around to have a closer look at the winCE branch.
Thank you for taking the time to look at it. 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. > Note that the Windows backend chose not to reference WinUSB.h > and link against WinUSB.lob because it was a headache to do so for all > of MSVC, cygwin, MinGW and WDK, and hooking directly into the DLL > avoided adding an extra dependency. But maybe this approach doesn't make > as much sense for CEUSBKWrapper, and you could avoid DLL_LOAD and use a > CEUSBKWrapper.h directly to simplify things. Still, either way is fine > with me. 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. > - 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. > Note that I don't have much of an issue taking care of the above during > integration, if you don't have a chance to address them, especially as > I'm going to merge and reorganize some of your patches anyway. The only > issue is that I can't be able to test further than compiling the code. > But I can create a CE integration branch and give you some chance to > test it, before it gets merged into mainline. I'm happy to make the changes myself (when I get time) and then test them. If you do make the changes yourself then I'm happy to take a branch and test it before it gets merged into mainline. > * Minor issues (can be left for after integration) > - The wince directory uses subdirectories for the project files > (libusb-1.0, listdevs), whereas the msvc one doesn't. With these > subdirectories only containing one file, I think they are a bit > unnecessary and we probably want to follow the same approach in both > instances. Likewise, the project files just places all the .c at the > same level, whereas you have an os/ and wince/ group. The .def is also > better placed in the "Resource Files" category That's a good point. It would be good to be consistent between the different platforms; I wasn't really thinking when I created the os and wince groups. > - The project is only set to build a DLL. Do you think there will be > many CE users to wanting to build a static library? If so, we may want > to have both a static and dynamic lib project as with the regular > Windows backend. It's simple enough to add building as a static lib and it might help someone so I'm happy to do this. > - 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)"? > - Using /msvc for non CE Windows is going to become a misnomer, since > MSVC/VS also applies for CE users, so maybe we should rename it. Or we > could use something /msvc_wince for CE and which should make it more > explicit that /msvc is for Windows x86_32/x86_64 (and most likely > Windows RT) I like the idea of /msvc_wince. 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
