Hi Hendrik, > >> >> > 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.
pulled and pushed back out. > >> 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. I want that BtOBEX* API calls always available and we should just define bdaddr_t if it is not defined by a previous include. > 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 :) I agree that needs work and I am happy to accept patches. Regards Marcel ------------------------------------------------------------------------------ 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
