I think I’ve got it now. There’s no ext.String or ext.Array anymore (which were annoying), and I have fixed the code for commenting out conflicting properties through BuildHX.

When it writes externs, it will include both the static and instance declarations, but when they conflict it should have been automatically commenting out the instance version. A newline was messing that up :)

The build process is really simple to understand, so that’s really cool ;)

Thanks for your work !!

I have updated the “build.xml” file for Sencha Touch, fixed the empty type issue in BuildHX, and have updated both haxelibs.

If you are able, please test against the current “senchatouch” haxelib and see if it is working for you.

Did it feel difficult to compile against the “build.xml” file on your own, and make changes? One of my hopes in creating this build system is that it would help improve the reliability of extern libraries, while making it easy to compile against new versions as they are released.

If externs are done by hand, it is daunting to consider updating when a new original version comes out. I had hoped that the XML approach would feel comfortable enough for anyone hacking an extern library, while making it simple to integrate those fixes into the official project.

Oh, I also added a “haxelib run buildhx install” command which helps install JSDuck on a Mac or Linux. I had hoped they would have a standalone binary we could include in the project, but this will do for now. Should hopefully make it easier for the future.

Later, I had envisioned a refactor of the NME command-line tools which would be “buildhx”

For now, “buildhx” is being used for externs, but I’m still interested in that idea. Whether they are separate from NME, or are still the NME command-line tools, I think we might all benefit by having flexibility in tooling.

Instead of having tools which are too opinionated, they can provide options. Then we could decide if we would prefer to use NME native code, Javascript, AIR or other methods of packaging and deploying content for each platform.

For the changes, I’ve added this two lines to the build.xml to ignore the Array and String classes :

< class name="Ext.Array" ignore="true" / >
< class name="Ext.String" ignore="true" / >

For BuildHX, I’ve just updated the line where jsduck is launched, to use the one that is installed on my computer (the 3.11 version), but I’m not sure if that’s relevant to add this to the official project…
Instead I think it will be good to have an automated process to install it (assuming ruby is installed …) or just download the last version into the bin directory …

For the optional arguments, I’ve not found where the problem is yet, but I do intend to find out :D For the senchatouch externals, I’ve fixed the problem manually…

Do you think it would be possible to share the changes to Sencha Touch’s “build.xml” file and the improvements you made to BuildHX so I can bake them into the official projects?

Would be great. Thank you!