Using Max code in XCode

Miscellaneous Forums/MacOS X Discussion/Using Max code in XCode

The forum is locked. These are the original blitzbasic.com forums, kept so they can still be read. No new topics, replies or edits can be made here. To join in, head over to the Blitz3D+ forums.

Dude, you give up too easily. There's no reason why this cannot be made to work and I'm determined to get it going because it's something I've been meaning to do myself for some time. I'd be surprised if nobody else has managed to use Xcode as an IDE for Blitz Max up until now, or at least looked into it, given the limitations of the Blitz IDE and the obvious advantages of doing all development work from within Xcode.

In reply to some of your questions, just copying the entire Blitz modules directory into your project won't work. It's a proprietary BRL structure which Xcode knows nothing about - unless you also define individual search paths (for the linker) to each folder containing a module library. Sure you can compile it ok, but the error messages you're getting are coming from the linker. It needs to locate each and every externally referenced symbol in order to build the target.

I have built two private frameworks: brl and pub, from the respective Blitz module directories. I think this is the best way to go, as you can set up dependencies in Xcode to rebuild them as targets whenever the Blitz modules are synchronized (your project in turn declares them as dependencies).

The only potential problems I see are the limitations of the interface between C/C++/ObjC and Blitz, i.e. the calling conventions etc, for which very limited documentation has been supplied. I need to take a good look at the source code, particularly for BMK. Also, the startup code for the Blitz runtime may need to be extracted or made externally accessible, so that it can be initialized by the host application.

I'll be working on it over the next few days whenever I can find some time and I'll post some more when I have anything. If I can get it all working, then on to the real challenge - fully integrating the Xcode debugger.