From: Denis K. <den...@tr...> - 2007-06-24 04:46:18
|
Hi, I wanted to see how easily OpenOBEX compiles on Visual Studio 2005. Overall it wasn't too bad, but required a bit of effort. Attached is a patch to make it compile. I've tested successfully with TCP transport. Some notes: Library: - Visual C++ compilers don't and probably never will support C99 semantics. Thus C99 struct initialization & variable declaration must be done the old way. - Win32 understands send and recv for sockets, not read and write - Win32 doesn't have stdint.h, had to fake it, see attached obex_stdint.h - Win32 doesn't have inet_ntop, had to fake it - Fixed a bug where obex client resets its mode to server before delivering an event (this broke obex_test) - Win32 doesn't support symlinks, had to manually copy headers to include/openobex. This needs a better solution. Can we move includes to include/openobex in the source tree? Applications: - Made a very basic effort to compile obex_test app. Seems to work. -Denis ----------------------------------------- Trolltech ASA, Sandakerveien 116, PO Box 4332, Nydalen NO-0402 Oslo, Norway |
From: Hendrik S. <po...@he...> - 2007-06-24 11:52:46
|
Am Sonntag 24 Juni 2007 06:46 schrieb Denis Kenzior: > I wanted to see how easily OpenOBEX compiles on Visual Studio 2005. > Overall it wasn't too bad, but required a bit of effort. Attached is a > patch to make it compile. I've tested successfully with TCP transport. > > Some notes: > > Library: > - Visual C++ compilers don't and probably never will support C99 > semantics. Thus C99 struct initialization & variable declaration must be > done the old way. Could be but that really sucks :-( You cannot just assign in6addr_loopback, you have to memcpy() it. > - Win32 understands send and recv for sockets, not read and write Should be already solved by the win32 patchset. From other patch lines, I clearly see that you did not use it. > - Win32 doesn't have stdint.h, had to fake it, see attached obex_stdint.h For normal cases, uses inttypes.h instead. One of both is present everywhere but stdint.h always includes inttypes.h and the latter actually defines what we want. Doesn't VC++ have inttypes.h? > - Win32 doesn't have inet_ntop, had to fake it Is that worth the effort for a _Debug_ message? Isn't there a WSA function that comes close to it and could be used? > - Fixed a bug where obex client resets its mode to server before > delivering an event (this broke obex_test) Seperate patch, then, as it's not related to the other stuff. > - Win32 doesn't support symlinks, had to manually copy headers to > include/openobex. This needs a better solution. Can we move includes to > include/openobex in the source tree? Yes, see win32 patchset. I already suggested that, too. A vcproj file could be generated by meta compilers, e.g. CMake. The latter doesn't support cross-compiling, yet, though. HS |
From: Hendrik S. <po...@he...> - 2007-07-14 08:27:15
|
Am Sonntag 24 Juni 2007 06:46 schrieb Denis Kenzior: > I wanted to see how easily OpenOBEX compiles on Visual Studio 2005. > Overall it wasn't too bad, but required a bit of effort. Attached is a > patch to make it compile. I've tested successfully with TCP transport. Yes, it requires quite some changes. After writing the CMake rule files, creating the VCExpress solution file was an easy task. I didn't manage to compile the thing, yet! This msvc compiler is just so broken and incompatible, that really sucks. Where shall I start: - doesn't know "inline" but "__inline" - says that "strncpy" is deprecated (what the f***) - needs to include io.h when using read or write - must define write as _write - must define read as _read - doesn't eat the current construct of BDADDR_ANY, must be the address of an extern variable instead .... Quite some differences, I'd say. Possible but Microsoft REALLY sucks here. Why can't the do like the rest of the world? Oh yeah, I forgot, they only support C++, not C. I did just a quick hack and got the library built (with excluded USB support). Maybe I open my own subversion respository with trac and with a complete openobex-win32 port as there is no such thing as quilt for win32 and that makes it a real pain to create fine patches when you already had to patch after checkout :-( My point is, though: the cmake files create working VC solutions files. I'll open a ticket for easier download and update. If you have a better clue about MSVC, maybe you can make the change the win32 patches and test the cmake files. OTOH, the gcc compiled lib will also work for MSVC, so the need to actually support MSVC is not that big. HS |