Zitat von Marcel Holtmann <mar...@holtmann.org>: >> >> > I also started fixing out screwed up declarations overload. Hope that >> >> > works now as expected. >> >> >> >> Let me test those changes for the Win32 build before release, please! >> >> It might needs other changes. I will tell you when I'm done with this. >> > >> > Sure. Let me know when you have verified it. >> >> It is currently broken on Win32 (all compilers). >> I can fix it but I need a bit time to figure out the bits.
The necessary changes are in my "updates" branch on gitorious. With that, I can build on Win32 using MSVC9. >> Regarding the BtOBEX_* functions: the main problem for testing for >> SOL_RFCOMM is that if bluetooth/bluetooth.h is not available (in >> Linux), then that define also isn't. This would leave bdaddr_t an >> undefined type. So if a user of OpenObex doesn't need bluetooth, that >> makes it work for him. >> Having bluez_compat.h includes should give you that define. >> The solution may be to define (or typedef) bdaddr_t as a basic type >> (or void*) if SOL_RFCOMM is not defined (thus adding an else case) and >> add the function prototype unconditionally. >> Using -Werror without this makes bluetooth a hard dependency (a no-go >> for many systems where there is no bluetooth stack). > > So my take is that these functions should always be present, but when > compiled without Bluetooth support, they return an error. > > The current state with having a different API depending on how it is > compiled is not a good thing anyway. The problem really is the definition of bdaddr_t. For openobex-internal usage, this needs to be the same as in bluez_compat.h and must not be defined twice. Thus, bluez_compat.h must always be included before openobex/obex.h. This can be ensured with a small header wrapper. For external usage, the definition depends on bluetooth being actually available. Even on Linux, this is not always the case, so either you hide the prototypes (doesn't really change the API) or you make bluetooth mandatory and include the bdaddr_t definitions from bluez_compat.h in there. The internal headers are also a bit messed up (quite a lot circular includes, e.g. between obex_main.h and obex_object.h). This needs cleanup, too, or you will always run into some kind of trouble easily. At some points, we only include openobex/obex.h because those damn typedefs are defined there. I propose for internal usage only the use of "struct xyz" instead of "xyz_t" and only include openobex/obex.h where absolutely necessary (mostly only lib/obex.c). This needs more work, though. Suggestion or counter arguments welcome :) HS ------------------------------------------------------------------------------ Register Now for Creativity and Technology (CaT), June 3rd, NYC. CaT is a gathering of tech-side developers & brand creativity professionals. Meet the minds behind Google Creative Lab, Visual Complexity, Processing, & iPhoneDevCamp as they present alongside digital heavyweights like Barbarian Group, R/GA, & Big Spaceship. http://p.sf.net/sfu/creativitycat-com _______________________________________________ Openobex-users mailing list Openobex-users@lists.sourceforge.net http://lists.sourceforge.net/lists/listinfo/openobex-users
