summaryrefslogtreecommitdiff
path: root/README.EXT_SKEL
diff options
context:
space:
mode:
authorHartmut Holzgraefe <hholzgra@php.net>2003-06-29 12:21:58 (GMT)
committerHartmut Holzgraefe <hholzgra@php.net>2003-06-29 12:21:58 (GMT)
commit7218a70ff684e476a2fd4f0ed75a466de5f5c724 (patch)
treedd197ca646a537e508e45f6e249f434b3cb119e3 /README.EXT_SKEL
parent4aa81c9d72395c5f8ca0a6decef51c6eff1904be (diff)
downloadphp-7218a70ff684e476a2fd4f0ed75a466de5f5c724.tar.gz
ext_skel is no more, and ext_skel_ng is moving to PEAR::PECL_Gen
Diffstat (limited to 'README.EXT_SKEL')
-rw-r--r--README.EXT_SKEL195
1 files changed, 2 insertions, 193 deletions
diff --git a/README.EXT_SKEL b/README.EXT_SKEL
index afe03cb..261f72c 100644
--- a/README.EXT_SKEL
+++ b/README.EXT_SKEL
@@ -1,193 +1,2 @@
-(NOTE: you may also want to take a look at scripts/ext_skel_ng,
- a PHP-only alternative for this script thats supposed
- to replace it completely in the long run ...)
-
-WHAT IT IS
-
- It's a tool for automatically creating the basic framework for a PHP module
- and writing C code handling arguments passed to your functions from a simple
- configuration file. See an example at the end of this file.
-
-HOW TO USE IT
-
- Very simple. First, change to the ext/ directory of the PHP 4 sources. If
- you just need the basic framework and will be writing all the code in your
- functions yourself, you can now do
-
- ./ext_skel --extname=module_name
-
- and everything you need is placed in directory module_name.
-
- [ Note that GNU awk is likely required for this script to work. Debian
- systems seem to default to using mawk, so you may need to change the
- #! line in skeleton/create_stubs and the cat $proto | awk line in
- ext_skel to use gawk explicitly. ]
-
- If you don't need to test the existence of any external header files,
- libraries or functions in them, the module is already almost ready to be
- compiled in PHP. Just remove 3 comments in your_module_name/config.m4,
- change back up to PHP sources top directory, and do
-
- ./buildconf; ./configure --enable-module_name; make
-
- But if you already have planned the overall scheme of your module, what
- functions it will contain, their return types and the arguments they take
- (a very good idea) and don't want to bother yourself with creating function
- definitions and handling arguments passed yourself, it's time to create a
- function definitions file, which you will give as an argument to ext_skel
- with option
-
- --proto=filename.
-
-FORMAT OF FUNCTION DEFINITIONS FILE
-
- All the definitions must be on one line. In it's simplest form, it's just
- the function name, e.g.
-
- my_function
-
- but then you'll be left with an almost empty function body without any
- argument handling.
-
- Arguments are given in parenthesis after the function name, and are of
- the form 'argument_type argument_name'. Arguments are separated from each
- other with a comma and optional space. Argument_type can be one of int,
- bool, double, float, string, array, object or mixed.
-
- An optional argument is separated from the previous by an optional space,
- then '[' and of course comma and optional space, like all the other
- arguments. You should close a row of optional arguments with same amount of
- ']'s as there where '['s. Currently, it does not harm if you forget to do it
- or there is a wrong amount of ']'s, but this may change in the future.
-
- An additional short description may be added after the parameters.
- If present it will be filled into the 'proto' header comments in the stubs
- code and the <refpurpose> tag in the XML documentation.
-
- An example:
-
- my_function(int arg1, int arg2 [, int arg3 [, int arg4]]) this is my 1st
-
- Arguments arg3 and arg4 are optional.
-
- If possible, the function definition should also contain it's return type
- in front of the definition. It's not actually used for any C code generating
- purposes but PHP in-source documentation instead, and as such, very useful.
- It can be any of int, double, string, bool, array, object, resource, mixed
- or void.
-
- The file must contain nothing else but function definitions, no comments or
- empty lines.
-
-OTHER OPTIONS
-
- --no-help
-
- By default, ext_skel creates both comments in the source code and a test
- function to help first time module writers to get started and testing
- configuring and compiling their module. This option turns off all such things
- which may just annoy experienced PHP module coders. Especially useful with
-
- --stubs=file
-
- which will leave out also all module specific stuff and write just function
- stubs with function value declarations and passed argument handling, and
- function entries and definitions at the end of the file, for copying and
- pasting into an already existing module.
-
- --assign-params
- --string-lens
-
- By default, function proto 'void foo(string bar)' creates the following:
- ...
- zval **bar;
- ... (zend_get_parameters_ex() called in the middle...)
- convert_to_string_ex(bar);
-
- Specifying both of these options changes the generated code to:
- ...
- zval **bar_arg;
- int bar_len;
- char *bar = NULL;
- ... (zend_get_parameters_ex() called in the middle...)
- convert_to_string_ex(bar_arg);
- bar = Z_STRVAL_PP(bar_arg);
- bar_len = Z_STRLEN_PP(bar_arg);
-
- You shouldn't have to ask what happens if you leave --string-lens out. If you
- have to, it's questionable whether you should be reading this document.
-
- --with-xml[=file]
-
- Creates the basics for phpdoc .xml file.
-
- --full-xml
-
- Not implemented yet. When or if there will ever be created a framework for
- self-contained extensions to use phpdoc system for their documentation, this
- option enables it on the created xml file.
-
-CURRENT LIMITATIONS, BUGS AND OTHER ODDITIES
-
- Only arguments of types int, bool, double, float, string and array are
- handled. For other types you must write the code yourself. And for type
- mixed, it wouldn't even be possible to write anything, because only you
- know what to expect.
-
- It can't handle correctly, and probably never will, variable list of
- of arguments. (void foo(int bar [, ...])
-
- Don't trust the generated code too much. It tries to be useful in most of
- the situations you might encounter, but automatic code generation will never
- beat a programmer who knows the real situation at hand. ext_skel is generally
- best suited for quickly generating a wrapper for c-library functions you
- might want to have available in PHP too.
-
- This program doesn't have a --help option. It has --no-help instead.
-
-EXAMPLE
-
- The following _one_ line
-
- bool my_drawtext(resource image, string text, resource font, int x, int y [, int color])
-
- will create this function definition for you (note that there are a few
- question marks to be replaced by you, and you must of course add your own
- value definitions too):
-
-/* {{{ proto bool my_drawtext(resource image, string text, resource font, int x, int y[, int color])
- */
-PHP_FUNCTION(my_drawtext)
-{
- zval **image, **text, **font, **x, **y, **color;
- int argc;
- int image_id = -1;
- int font_id = -1;
-
- argc = ZEND_NUM_ARGS();
- if (argc < 5 || argc > 6 || zend_get_parameters_ex(argc, &image, &text, &font, &x, &y, &color) == FAILURE) {
- WRONG_PARAM_COUNT;
- }
-
- ZEND_FETCH_RESOURCE(???, ???, image, image_id, "???", ???_rsrc_id);
- ZEND_FETCH_RESOURCE(???, ???, font, font_id, "???", ???_rsrc_id);
-
- switch (argc) {
- case 6:
- convert_to_long_ex(color);
- /* Fall-through. */
- case 5:
- convert_to_long_ex(y);
- convert_to_long_ex(x);
- /* font: fetching resources already handled. */
- convert_to_string_ex(text);
- /* image: fetching resources already handled. */
- break;
- default:
- WRONG_PARAM_COUNT;
- }
-
- php_error(E_WARNING, "my_drawtext: not yet implemented");
-}
-/* }}} */
-
+NOTE: ext_skel does no longer exist, it has been replaced
+ by the PEAR package PECL_Gen