I'm fine with your solution but I was hoping we could find a way to prevent this extra work on your side. If you plan on following orx, I'll inform you when releases are made (next one is currently scheduled for early may) but if you prefer you can also subscribe to orx's development mailing list (you'll find it via orx's sourceforge page).AGS wrote:I've just checked out the source code of the .h files and looked at the functions declared inline. The orxSTRING and the orxMATH module are the ones that use inline functions a lot and orxSTRING has some lengthy ones. The other modules use inline here and there (mostly one liners combined with assertions).
I would suggest the following solution.
Inline functions can be translated to FB macros. As the inlined functions are declared static they cannot be seen from FB code so using the FB macros instead of the inline funtions should not pose a problem. Of course rewriting of those inline functions will be done by me.
I had planned to be translating the inline functions to FB macros from the start so to me it's just 'part of the plan' (I had expected to be doing so anyway).
If I use macros it will get a bit harder for duke4e to port his app from FB to C as he would not be able to use the macros as functions.
Something likewould becomeCode: Select all
<macro_name><argument_list,s> etc....
in C.Code: Select all
s = <function_name><argument_list> etc.....
My solution does mean I'd have to follow changes in the orx code but I don't think that's a major problem.
For now I think the macro solution will do. I wanna get that orx lib working asap and using the macro solution I should be able to get it to work.
The problem with the dynamic link library had to do with pexports adding DATA to every line. I thought that was a bit weird as pexports usually does not do that.
The dll, however, worked as it should so stripping DATA from the lines produced by pexports could be enough to use i's output with dlltool.
So I can actually put that import library together. I do not remember, however, seeing any symbols from the SFML library inside the dll.
If I get the macros solution to work I think I'd still need to have those SFML related files or I'll be getting linker errors.
As for the missing external symbols, they are not exported in the DLL (as being extern to orx) but the corresponding code should however be present as those links are resolved when the DLL is built/linked.
However this isn't the case when building a static library as static libraries are mere gatherings of all built objects (ie. there's no link stage), hence needing to manually embed the external object files as well. In order to do so I simply need to extract all .o from libBox2D.a and the other external libraries, then pack them into liborx.a.
As for the static version, I'll update the package tomorrow and I'll include Box2D & SFML code/symbols into liborx.a. I couldn't do it before as I don't have access to binutils on my laptop.
I'll keep you posted when it's done.
Thanks! Things are going very smoothly lately: everything seems to work well so far.Good luck on porting orx to the iphone!
I simply need to add text and sound support in order to finish the port.
I also added code to catch/relay multiple touches & accelerometer/motion info, but I can't test it on the iPhone simulator.
Testing on a real device requires to register to Apple's IDP program which costs 99$/year. So this part will wait a bit. :)