mirror of https://github.com/axmolengine/axmol.git
75 lines
3.7 KiB
INI
75 lines
3.7 KiB
INI
|
[cocos2dx_extension]
|
||
|
# the prefix to be added to the generated functions. You might or might not use this in your own
|
||
|
# templates
|
||
|
prefix = cocos2dx_extension
|
||
|
|
||
|
# create a target namespace (in javascript, this would create some code like the equiv. to `ns = ns || {}`)
|
||
|
# all classes will be embedded in that namespace
|
||
|
target_namespace = cc
|
||
|
|
||
|
android_headers =
|
||
|
|
||
|
android_flags = -target armv7-none-linux-androideabi -D_LIBCPP_DISABLE_VISIBILITY_ANNOTATIONS -DANDROID -D__ANDROID_API__=14 -gcc-toolchain %(gcc_toolchain_dir)s --sysroot=%(androidndkdir)s/platforms/android-14/arch-arm -idirafter %(androidndkdir)s/sources/android/support/include -idirafter %(androidndkdir)s/sysroot/usr/include -idirafter %(androidndkdir)s/sysroot/usr/include/arm-linux-androideabi -idirafter %(clangllvmdir)s/lib64/clang/5.0/include -I%(androidndkdir)s/sources/cxx-stl/llvm-libc++/include
|
||
|
|
||
|
clang_headers =
|
||
|
clang_flags = -nostdinc -x c++ -std=c++11 -fsigned-char -U__SSE__
|
||
|
|
||
|
cocos_headers = -I%(cocosdir)s -I%(cocosdir)s/cocos/editor-support -I%(cocosdir)s/cocos -I%(cocosdir)s/cocos/platform/android -I%(cocosdir)s/external -I%(cocosdir)s/external/json
|
||
|
|
||
|
cocos_flags = -DANDROID
|
||
|
|
||
|
cxxgenerator_headers =
|
||
|
|
||
|
# extra arguments for clang
|
||
|
extra_arguments = %(android_headers)s %(clang_headers)s %(cxxgenerator_headers)s %(cocos_headers)s %(android_flags)s %(clang_flags)s %(cocos_flags)s %(extra_flags)s
|
||
|
|
||
|
# what headers to parse
|
||
|
headers = %(cocosdir)s/extensions/cocos-ext.h
|
||
|
|
||
|
# what classes to produce code for. You can use regular expressions here. When testing the regular
|
||
|
# expression, it will be enclosed in "^$", like this: "^Menu*$".
|
||
|
classes = Control.* ControlButton.* ScrollView$ TableView$ TableViewCell$ AssetsManager AssetsManagerEx Manifest EventAssetsManagerEx EventListenerAssetsManagerEx PUParticleSystem3D ParticleSystem3D ParticlePool
|
||
|
|
||
|
# what should we skip? in the format ClassName::[function function]
|
||
|
# ClassName is a regular expression, but will be used like this: "^ClassName$" functions are also
|
||
|
# regular expressions, they will not be surrounded by "^$". If you want to skip a whole class, just
|
||
|
# add a single "*" as functions. See bellow for several examples. A special class name is "*", which
|
||
|
# will apply to all class names. This is a convenience wildcard to be able to skip similar named
|
||
|
# functions from all classes.
|
||
|
|
||
|
skip = .*Delegate::[*],
|
||
|
.*Loader.*::[*],
|
||
|
*::[^visit$ copyWith.* onEnter.* onExit.* ^description$ getObjectType (g|s)etDelegate .*HSV],
|
||
|
EditBox::[(g|s)etDelegate ^keyboard.* touchDownAction getScriptEditBoxHandler registerScriptEditBoxHandler unregisterScriptEditBoxHandler],
|
||
|
ControlUtils::[*],
|
||
|
ControlSwitchSprite::[*],
|
||
|
ScrollView::[(g|s)etDelegate$],
|
||
|
TableView::[create (g|s)etDataSource$ (g|s)etDelegate],
|
||
|
Manifest::[getAssets],
|
||
|
EventListenerAssetsManagerEx::[create],
|
||
|
PUParticleSystem3D::[getDerivedOrientation getEmittedEmitterParticlePool getEmittedSystemParticlePool getAffector getEmitter getObserver],
|
||
|
ParticlePool::[getActiveParticleList createParticle getNext getFirst],
|
||
|
ParticleSystem3D::[getParticlePool getAffector]
|
||
|
|
||
|
|
||
|
rename_functions =
|
||
|
|
||
|
rename_classes =
|
||
|
|
||
|
# for all class names, should we remove something when registering in the target VM?
|
||
|
remove_prefix =
|
||
|
|
||
|
# classes for which there will be no "parent" lookup
|
||
|
classes_have_no_parents =
|
||
|
|
||
|
# base classes which will be skipped when their sub-classes found them.
|
||
|
base_classes_to_skip =
|
||
|
|
||
|
# classes that create no constructor
|
||
|
# Set is special and we will use a hand-written constructor
|
||
|
abstract_classes = ArmatureDataManager Manifest
|
||
|
|
||
|
# Determining whether to use script object(js object) to control the lifecycle of native(cpp) object or the other way around. Supported values are 'yes' or 'no'.
|
||
|
script_control_cpp = no
|
||
|
|