mirror of https://github.com/axmolengine/axmol.git
Delete README.md
This commit is contained in:
Deal(一线灵)
GitHub
parent
68774d8319
commit
47ba2e6644
|
|
@ -1,159 +0,0 @@
|
||||||
# What's new
|
|
||||||
* Add a prebuilt libclang 5.0 in `libclang/`for mac, linux and windows.
|
|
||||||
* If you want use the prebuilt licbclang 5.0 work with Android NDK, then `only the NDK r16 (or higher version) can work corrently` with it.
|
|
||||||
|
|
||||||
# Requirements
|
|
||||||
|
|
||||||
* python2.7
|
|
||||||
* py-yaml
|
|
||||||
* cheetah (for target language templates)
|
|
||||||
|
|
||||||
# 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
|
|
||||||
|
|
||||||
* The test uses the prebuilt 5.0 libclang, so you should use `Android NDK r16` or higher version.
|
|
||||||
* The test uses <string> and <stdint.h> so you need a C++ implementation that provides these
|
|
||||||
* Currently, the test script is setup to use the Android NDK's llvm libc++
|
|
||||||
|
|
||||||
### Mac OS X
|
|
||||||
|
|
||||||
* The OSX 10.9 has a built-in python2.7 and if your os don't have python2.7 then use [Homebrew](http://brew.sh/) to install the python and use pip install the python dependencies.
|
|
||||||
<pre>
|
|
||||||
brew install python
|
|
||||||
</pre>
|
|
||||||
|
|
||||||
* Install python dependices by pip.
|
|
||||||
<pre>
|
|
||||||
sudo easy_install pip
|
|
||||||
sudo pip install PyYAML
|
|
||||||
sudo pip install Cheetah
|
|
||||||
</pre>
|
|
||||||
|
|
||||||
* Download [NDK r16](https://dl.google.com/android/repository/android-ndk-r16-darwin-x86_64.zip) from [google](https://developer.android.com/ndk/downloads/index.html)
|
|
||||||
* If you are using python installed from other way, copy user.cfg.sample and rename it as `user.cfg` then set the absolute path to python `PYTHON_BIN` in `user.cfg`
|
|
||||||
* Run follow command, it will generate a `userconf.ini`, and check the values in it if it occorus any error.
|
|
||||||
<pre>
|
|
||||||
export ANDROID_NDK=/path/to/android-ndk-r16
|
|
||||||
./test.sh
|
|
||||||
</pre>
|
|
||||||
|
|
||||||
### Ubuntu Linux 12.04 64bit
|
|
||||||
* Install python
|
|
||||||
<pre>
|
|
||||||
sudo apt-get install python2.7
|
|
||||||
</pre>
|
|
||||||
* Install python dependices by pip.
|
|
||||||
<pre>
|
|
||||||
sudo apt-get install python-pip
|
|
||||||
sudo pip install PyYAML
|
|
||||||
sudo pip install Cheetah
|
|
||||||
</pre>
|
|
||||||
* Download [NDK r16](https://dl.google.com/android/repository/android-ndk-r16-linux-x86_64.zip) from [google](https://developer.android.com/ndk/downloads/index.html)
|
|
||||||
* If you are using python installed from other way, copy user.cfg.sample and rename it as `user.cfg` then set the absolute path to python `PYTHON_BIN` in `user.cfg`
|
|
||||||
* Run follow command, it will generate a `userconf.ini`, and check the values in it if it occorus any error.
|
|
||||||
<pre>
|
|
||||||
export ANDROID_NDK=/path/to/android-ndk-r16
|
|
||||||
./test.sh
|
|
||||||
</pre>
|
|
||||||
|
|
||||||
### Windows 7 64bit
|
|
||||||
* Download python2.7.3 (`32bit`) from (http://www.python.org/ftp/python/2.7.3/python-2.7.3.msi).
|
|
||||||
* Add the installed path of python (e.g. C:\Python27) to windows environment variable named 'PATH'.
|
|
||||||
* Download pyyaml from http://pyyaml.org/download/pyyaml/PyYAML-3.10.win32-py2.7.exe and install it.
|
|
||||||
* Download [Cheetah-2.4.4.tar.gz](https://pypi.python.org/packages/cd/b0/c2d700252fc251e91c08639ff41a8a5203b627f4e0a2ae18a6b662ab32ea/Cheetah-2.4.4.tar.gz#md5=853917116e731afbc8c8a43c37e6ddba), extract and install it by `python setup.py`.
|
|
||||||
* Download [NDK r16](https://dl.google.com/android/repository/android-ndk-r16-windows-x86_64.zip) from [google](https://developer.android.com/ndk/downloads/index.html)
|
|
||||||
* Set the environment variables (`PYTHON_ROOT` and `ANDROID_NDK`) or just them in `test.bat`.
|
|
||||||
* Run "test.bat". The generated codes will be under "simple_test_bindings".
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
### 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
|
|
||||||
|
|
||||||
* A .hpp header file for the bindings class
|
|
||||||
* A .cpp file implementing the bindings class
|
|
||||||
* A .js file that documents how to call (from JavaScript) the methods the C++ class exposes
|
|
||||||
|
|
||||||
# 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 axmol
|
|
||||||
|
|
||||||
[axmol]
|
|
||||||
prefix = axmol
|
|
||||||
events = CCNode#onEnter CCNode#onExit
|
|
||||||
extra_arguments = -I../../axmol/include -I../../axmol/platform -I../../axmol/platform/ios -I../../axmol -I../../axmol/kazmath/include -arch i386 -DTARGET_OS_IPHONE -isysroot /Applications/Xcode.app/Contents/Developer/Platforms/iPhoneSimulator.platform/Developer/SDKs/iPhoneSimulator5.1.sdk -x c++
|
|
||||||
headers = ../../axmol/include/axmol.h
|
|
||||||
classes = CCSprite
|
|
||||||
functions = my_free_function
|
|
||||||
|
|
||||||
## Required sections
|
|
||||||
|
|
||||||
* prefix: the prefix for the project. Must be a valid identifier for the language of the target vm.
|
|
||||||
Most of the time, the name will be intermixed between the class name and the function name, since
|
|
||||||
all generated (probably) will be free functions, we do that in order to avoid name collition. The
|
|
||||||
script will generate ${prefix}.cpp and ${prefix}.hpp as a result.
|
|
||||||
* events: a list of identifiers in the form of ClassName#functionName that are events to be called
|
|
||||||
from the native world to the target vm.
|
|
||||||
* extra_arguments: extra arguments to pass to the clang interface. Basically you can think of this
|
|
||||||
as the arguments to pass to the "compiler", so add as many as you need here. If you're targetting
|
|
||||||
C++, make sure you add "-x c++" as the last argument to force C++ mode on a ".h" file. Otherwise,
|
|
||||||
name your header files as ".hpp".
|
|
||||||
* headers: list of headers to parse. Usually you add a single header that in turn `#include`s the
|
|
||||||
rest of the files.
|
|
||||||
* classes: the classes that will be parsed. Right not is just a string, but it will accept regular
|
|
||||||
expressions
|
|
||||||
* functions: space-separated list of free functions to be binded. Same as with classes, it will
|
|
||||||
support regular expressions.
|
|
||||||
* skip: a space-separated list of `Classes::functions` or just `functions` to not generate any code.
|
|
||||||
|
|
||||||
# The templates
|
|
||||||
|
|
||||||
The generator is using [Cheetah templates](http://www.cheetahtemplate.org/) 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:
|
|
||||||
|
|
||||||
* prelude.c/.h: The header of the generated files.
|
|
||||||
* ifunction.c/.h: The template for an instance function
|
|
||||||
* ifunction_overloaded.c: The template for the implementation of an overloaded function. An
|
|
||||||
overloaded function is exactly the same as a function, but it has an array of functions sharing
|
|
||||||
the same name. The current implementation for spidermonkey only works if the overloading is with
|
|
||||||
different number of arguments.
|
|
||||||
* sfunction.c/.h: The template for a static function
|
|
||||||
* sfunction_overloaded.c: The template for an overloaded static function
|
|
||||||
* register.c: Here you should add the constructor/finalizer, the registration function (if needed)
|
|
||||||
and the footer of the header file. This is the last chunk being generated
|
|
||||||
|
|
||||||
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:
|
|
||||||
|
|
||||||
* variable number of arguments. Solution: write a manual wrapper
|
|
||||||
Loading…
Reference in New Issue