Stage 1 - the matcher and Arg_xxxx's , arg_types.php
The matcher is responsible for mapping the elements found in the defs file into C code. The objects are set up pior to doing the parsing, but are acutally used near the end of the process.
In the example below we will look at the method
$window->set_title("title");
This method recieves a string as an argument. - the definition file will say something like
(parameter (type-and-name const-gchar* string))
the arg_types.php file sets up all the methods need to output any of these element when they are found.
XXX_Arg::write_param
takes in a number of variables and returns them using the call by reference technique
it returns these key components
$var_list - the variable definitions - managed by the Var_List class
eg.
char * string;
$parse_list - the PHP parameter list - just a array of strings
eg.
&string
used to build
if (!php_gtk_parse_args(ZEND_NUM_ARGS(), "s", &string))
return;
$extra_post_code and $extra_pre_code
are used to handle some win32 compatibilty issues with utf8_ or add extra C code before and after the C function call.
returns "s" which makes up the 2nd argument of php_gtk_parse_args above.
XXX_Arg::write_return
is responsibe for the return values of a call - it returns a string ready to be used with sprintf eg. it may aslo add more variables to
$var_list
$ret = &s;\n" .
"%s if (ret) {\n".
" RETURN_STRING((char *)ret, 1);\n".
" }\n".
" else {\n".
" RETURN_NULL();\n".
" }";
XXX_Arg::write_to_prop
is used to deal with properties of an object = eg.
$widget->parent
for example Int_Arg returns
"add_property_long($obj, \"$name\", $source);\n";
XXX_Arg::write_from_prop
is used to set a property when the php code does something like
$label->text = "test";
for example the Arg_Int returns this
"if (zend_hash_find(Z_OBJPROP_P(wrapper),
\"$name\", sizeof(\"$name\"), (void **)&item)
== SUCCESS && Z_TYPE_PP(item) == IS_LONG)\n".
" obj->$name = Z_LVAL_PP(item);\n".
" else\n".
" return 0;\n\n";
Stage 2 - Overrides - override.php
the override reader breaks the override file by exploding on the (%%) keyword. each block is then dealt with depending on it's type,
the
header tag is simply stored raw, ready for output,
the
override and ingore tags are used to build an array of elements that the generator will ignore later.
Stage 3 - Defs_Parser - scheme.php
This reads the defs file, builds an array of all the items something like this
(function xxxxxx
(in-module yyyy)
(
$parse_tree[0] = array(
"function" // the type of argument
"xxxxx" // the name of the function
array( // a element of the definition.
"in-module"
"yyyy"
)
.... // and so on.. -
having done the parsing, it will store it in a cache file. (using serialize, eg. gtk.defs.cache) - this is done to save time processing the next time it is built.
Stage 4 - building the object tree definitions.php
Def_Parser::handle will pass the definition of the top level items to the Def_Paser::handle_$type = eg. Def_Paser::handle_function - these usually call methods like Function_Def etc. from
definitions.php The handler methods create an object based on the definition, and add it to the respective arrays in Def_Parser
Defs_Parser::functions[0] = object
Function_Def->in-module="yyyy"
Function_Def->name="xxxx"
Stage 5 - The Generation registing extra objects, structs etc. Generator::register_types() - generator.php
Prior to generating the code, the generator uses the information from the defs file to generate additional structs, objects etc. - in the
matcher (from stage1)
Stage 6 - The code generation Generator::create_source() - generator.php
this opens the stdout and starts writes in order,
headers (from overrides)
constants - from defs -
REGISTER_LONG_CONSTANT(
class entries - from defs/overrides eg.
PHP_GTK_EXPORT_CE(gtk_allocation_ce);
functions - from defs/overrides (which are really functions and methods)
structs - from defs/overrides
objects - which is the
php_gtk_register_classes(void)
{