Friday, April 28, 2006

haXe + Xcode

Note: I added a haXe Xcode project template to the haxeXcode.zip pacakge (5/5/2006)

It turns out that, with a bit of effort, you can turn Xcode into a solid haXe IDE.

First, Xcode can provide excellent code highlighting and auto completion for haXe. To enable them, you have to install haXe language support files. You don't need to go through the trouble of creating such files yourself -- go ahead and download the ones I created: haxeXcode.zip.

To install haXe language support, unzip the package, put haxe.pbfilespec and haxe.pblangspec in /Library/Application Support/Apple/Developer Tools/Specifications/ and restart Xcode (note: haXe code highlighting is only enabled for files ending with .hx). If you only want the plugin to be installed for your user account, make the root path ~/Library.



(To create the language definition files, I modified the script for generating Actionscript language tokens I found on mabwebdesign.com to parse haXe source and output haXe language tokens. I then modified the Actionscript language definition files provided with the original script to support the haXe language. As you can see, most of the work has already been done for me :) )

Second, the Xcode + MTASC trick I wrote about in a previous posting also works with haXe. You're probably too lazy to go back and read it, so I'll explain: if you call the haXe compiler from an Xcode shell script target, Xcode will correctly interpret haXe's error messages and point you at the problematic line in your code (tip: you can press Apple + '=' to jump to the error's location).



Here's the best way of setting up Xcode's build system for a haXe project:

- Create a new shell script target called 'build'.
- Edit the shell script to invoke the haXe compiler (example: "haxe compile.hxml").
- Create another shell script target called 'run'.
- Add the target 'build' to the new target's list of dependencies.
- Edit the 'run' script to open the generated swf (which you should embed in an html page) in Safari
(example: "open -a /Applications/Safari.app build/index.html")

When you set things up in this manner, if 'run' is your active target and haXe runs into a compilation error during 'build', Xcode will abort before reaching 'run' and Safari won't be opened, which would otherwise be a horribly annoying behavior. By my experience, this setup greatly speeds up development and testing.

Note: this is a new edit (5/5/2006). If you don't feel like going through all these steps yourself, you can install the haXe Xcode project template I created, which is included in haxeXcode.zip. Simply put the folder called "haXe Application" in /Library/Application Support/Apple/Developer Tools/Project Templates/Application and restart Xcode. Now, when you create a new project, you'll see "haXe Application" as an option under "Application." Just make sure to edit the "run" target's script to point at your location of the haXe executable. (The reason I chose to invoke Safari from a shell script is that the 'open' doesn't launch a new Safari process in case Safari is already running.)

Final tip: I set up CTRL-space as auto-complete key-combo. I use it all the time and it greatly speeds up coding.

Hope this helps! Let me know if you have any comments or suggestions.

9 comments:

Michael Florentin said...

Looks interesting! I've got some experience working with haXe the last few weeks but I'm a XCode novice - but I managed to get your stuff working.

A few experiences:

~/Library/... is just as good as /Library/... for the support files if you prefer to keep stuff local.

Instead of a "run" Target, I made a "Safari" Executable with "Executable path" set to "/Applications/Safari.app" and a single argument "$(PROJECT_DIR)/index.html". Then you don't have to switch target to build resp. run the flash.

For some strange reason, errors from previous build attempts keep piling up in my "Errors and Warnings" list. How do I clear the list automatically?

I think it would be neat, if you made a small project with a simple .xcodeproj with the right setup, a compile.hxml, and maybe a small Main.hx that could work as a project template. You just have to drop the project folder in your favorite Library/Application Support/Apple/Developer Tools/Project Templates folder to make it appear in the New Project wizard. The .xcodeproj package should also contain a simple TemplateInfo.plist. I'll look into it some other day if you don't beat me to it!

But thanks for your work! It just made XCode my preferred tool for haxing haXe!

Yariv Sadan said...

Michael, these are some great suggestions. I'll go ahead and make a "template" project for people to download.

I'm not sure why your error list keeps piling up. I'll try to see if I can replicate it somehow. It hasn't happened to me.

geekinger said...

Great little template Yariv. Michael, that pile up of errors happens to me too, there's gotta be a way, right?

Not being an expert either, I'm getting a couple errors. One change I had to make was setting the Target ~haxe/bin/haxe to ~/bin/haxe

Now when I do that I'm getting the error: Command /bin/sh failed with exit code 1.

any ideas?

best, Seth

Yariv said...

Seth, maybe you should try executing the haXe compiler from the terminal and seeing what error it returns. There could be a problem with your compile.hxml file or something...

geekinger said...

thnx Yariv, your suggestion helped. i had to put the std directory in the same location as the binary.

if you're interested,stop by the http://flashcodersny.org user group. Its usually about 10-15 people. Tomorrow we're discussing flex/as3 compiling.

Seth

Yariv said...

Seth, I couldn't make this meeting, but maybe I'll attend a future one.

marco said...

Great! thank you very much. Now I can start coding seriously with haXe

grahoom said...

hello - for xcode 3

haxe.pbfilespec and haxe.pblangspec

need to go into Developer/Library/PrivateFrameworks/XcodeEdit.framework/Resources/

haXe Application needs to go

Developer/Library/Xcode/Project Templates/Application

skin said...

Hi jusat thought Id comment that what you say is the procedure for xcode 3 grahoom doesn't actually work I believe the spec files haxe.pbfilespec and haxe.pblangspec need to be rewrittenin the new format...

http://talamathi.blogspot.com/2007/11/xcode-3-language-specification-changes.html

.. and renamed with correct extension.

I am not aware of this being done by anybody as yet but would be intereste if anybody new of anyone who has befor I attempt it myself.

G