cocos2d / bindings-generator

JSBindings generator for C++
170 stars 153 forks source link

What's new

Requirements

Usage

Usage: generator.py [options] {configfile}

Options:
  -h, --help   show this help message and exit
  -s SECTION   sets a specific section to be converted
  -t TARGET    specifies the target vm. Will search for TARGET.yaml

Basically, you specify a target vm (spidermonkey is the only current target vm) and the section from the .ini file you want to generate code for.

Run the simple test with prebuilt libclang 5.0

Included in this repository is a simple test. Use this to confirm the generator is working and that your environment is set up correctly.

NOTE

Mac OS X

Ubuntu Linux 12.04 64bit

Windows 7 64bit

Expected output

Upon running the test you might see some warnings but should not see any errors.

The test will create a directory named simple_test_bindings that contains 3 files

The .ini file

The .ini file is a simple text file specifying the settings for the code generator. Here's the default one, used for cocos2d-x

[cocos2d-x]
prefix = cocos2dx
events  = CCNode#onEnter CCNode#onExit
extra_arguments = -I../../cocos2dx/include -I../../cocos2dx/platform -I../../cocos2dx/platform/ios -I../../cocos2dx -I../../cocos2dx/kazmath/include -arch i386 -DTARGET_OS_IPHONE -isysroot /Applications/Xcode.app/Contents/Developer/Platforms/iPhoneSimulator.platform/Developer/SDKs/iPhoneSimulator5.1.sdk -x c++
headers = ../../cocos2dx/include/cocos2d.h
classes = CCSprite
functions = my_free_function

Required sections

The templates

The generator is using Cheetah templates to create a more flexible generator. The way it was thought, is that for every target environment, you should provide with a way to generate the same C/C++ functionality. Every template has access to the proper meta information for the code or generator (function, classes, etc.)

Right now it's separated in the following set of templates:

Templates are stored in the templates/${target} directory and follow the naming specified above.

One final part of the puzzle is the ${target}.yaml file, that contains specific type conversion snippets to be used by the templates. For instance, for spidermonkey, this is the place where we specify the conversion routines for the native types (to and from int, float, string, etc.)

Limitations

Currently the generator is leveraging clang in order to get information about the C/C++ code, so we can only get as much information as clang give us. Known list of things that won't work: