Skip to content

Commit 7218a70

Browse files
author
Hartmut Holzgraefe
committed
ext_skel is no more, and ext_skel_ng is moving to PEAR::PECL_Gen
1 parent 4aa81c9 commit 7218a70

33 files changed

+2
-4820
lines changed

README.EXT_SKEL

Lines changed: 2 additions & 193 deletions
Original file line numberDiff line numberDiff line change
@@ -1,193 +1,2 @@
1-
(NOTE: you may also want to take a look at scripts/ext_skel_ng,
2-
a PHP-only alternative for this script thats supposed
3-
to replace it completely in the long run ...)
4-
5-
WHAT IT IS
6-
7-
It's a tool for automatically creating the basic framework for a PHP module
8-
and writing C code handling arguments passed to your functions from a simple
9-
configuration file. See an example at the end of this file.
10-
11-
HOW TO USE IT
12-
13-
Very simple. First, change to the ext/ directory of the PHP 4 sources. If
14-
you just need the basic framework and will be writing all the code in your
15-
functions yourself, you can now do
16-
17-
./ext_skel --extname=module_name
18-
19-
and everything you need is placed in directory module_name.
20-
21-
[ Note that GNU awk is likely required for this script to work. Debian
22-
systems seem to default to using mawk, so you may need to change the
23-
#! line in skeleton/create_stubs and the cat $proto | awk line in
24-
ext_skel to use gawk explicitly. ]
25-
26-
If you don't need to test the existence of any external header files,
27-
libraries or functions in them, the module is already almost ready to be
28-
compiled in PHP. Just remove 3 comments in your_module_name/config.m4,
29-
change back up to PHP sources top directory, and do
30-
31-
./buildconf; ./configure --enable-module_name; make
32-
33-
But if you already have planned the overall scheme of your module, what
34-
functions it will contain, their return types and the arguments they take
35-
(a very good idea) and don't want to bother yourself with creating function
36-
definitions and handling arguments passed yourself, it's time to create a
37-
function definitions file, which you will give as an argument to ext_skel
38-
with option
39-
40-
--proto=filename.
41-
42-
FORMAT OF FUNCTION DEFINITIONS FILE
43-
44-
All the definitions must be on one line. In it's simplest form, it's just
45-
the function name, e.g.
46-
47-
my_function
48-
49-
but then you'll be left with an almost empty function body without any
50-
argument handling.
51-
52-
Arguments are given in parenthesis after the function name, and are of
53-
the form 'argument_type argument_name'. Arguments are separated from each
54-
other with a comma and optional space. Argument_type can be one of int,
55-
bool, double, float, string, array, object or mixed.
56-
57-
An optional argument is separated from the previous by an optional space,
58-
then '[' and of course comma and optional space, like all the other
59-
arguments. You should close a row of optional arguments with same amount of
60-
']'s as there where '['s. Currently, it does not harm if you forget to do it
61-
or there is a wrong amount of ']'s, but this may change in the future.
62-
63-
An additional short description may be added after the parameters.
64-
If present it will be filled into the 'proto' header comments in the stubs
65-
code and the <refpurpose> tag in the XML documentation.
66-
67-
An example:
68-
69-
my_function(int arg1, int arg2 [, int arg3 [, int arg4]]) this is my 1st
70-
71-
Arguments arg3 and arg4 are optional.
72-
73-
If possible, the function definition should also contain it's return type
74-
in front of the definition. It's not actually used for any C code generating
75-
purposes but PHP in-source documentation instead, and as such, very useful.
76-
It can be any of int, double, string, bool, array, object, resource, mixed
77-
or void.
78-
79-
The file must contain nothing else but function definitions, no comments or
80-
empty lines.
81-
82-
OTHER OPTIONS
83-
84-
--no-help
85-
86-
By default, ext_skel creates both comments in the source code and a test
87-
function to help first time module writers to get started and testing
88-
configuring and compiling their module. This option turns off all such things
89-
which may just annoy experienced PHP module coders. Especially useful with
90-
91-
--stubs=file
92-
93-
which will leave out also all module specific stuff and write just function
94-
stubs with function value declarations and passed argument handling, and
95-
function entries and definitions at the end of the file, for copying and
96-
pasting into an already existing module.
97-
98-
--assign-params
99-
--string-lens
100-
101-
By default, function proto 'void foo(string bar)' creates the following:
102-
...
103-
zval **bar;
104-
... (zend_get_parameters_ex() called in the middle...)
105-
convert_to_string_ex(bar);
106-
107-
Specifying both of these options changes the generated code to:
108-
...
109-
zval **bar_arg;
110-
int bar_len;
111-
char *bar = NULL;
112-
... (zend_get_parameters_ex() called in the middle...)
113-
convert_to_string_ex(bar_arg);
114-
bar = Z_STRVAL_PP(bar_arg);
115-
bar_len = Z_STRLEN_PP(bar_arg);
116-
117-
You shouldn't have to ask what happens if you leave --string-lens out. If you
118-
have to, it's questionable whether you should be reading this document.
119-
120-
--with-xml[=file]
121-
122-
Creates the basics for phpdoc .xml file.
123-
124-
--full-xml
125-
126-
Not implemented yet. When or if there will ever be created a framework for
127-
self-contained extensions to use phpdoc system for their documentation, this
128-
option enables it on the created xml file.
129-
130-
CURRENT LIMITATIONS, BUGS AND OTHER ODDITIES
131-
132-
Only arguments of types int, bool, double, float, string and array are
133-
handled. For other types you must write the code yourself. And for type
134-
mixed, it wouldn't even be possible to write anything, because only you
135-
know what to expect.
136-
137-
It can't handle correctly, and probably never will, variable list of
138-
of arguments. (void foo(int bar [, ...])
139-
140-
Don't trust the generated code too much. It tries to be useful in most of
141-
the situations you might encounter, but automatic code generation will never
142-
beat a programmer who knows the real situation at hand. ext_skel is generally
143-
best suited for quickly generating a wrapper for c-library functions you
144-
might want to have available in PHP too.
145-
146-
This program doesn't have a --help option. It has --no-help instead.
147-
148-
EXAMPLE
149-
150-
The following _one_ line
151-
152-
bool my_drawtext(resource image, string text, resource font, int x, int y [, int color])
153-
154-
will create this function definition for you (note that there are a few
155-
question marks to be replaced by you, and you must of course add your own
156-
value definitions too):
157-
158-
/* {{{ proto bool my_drawtext(resource image, string text, resource font, int x, int y[, int color])
159-
*/
160-
PHP_FUNCTION(my_drawtext)
161-
{
162-
zval **image, **text, **font, **x, **y, **color;
163-
int argc;
164-
int image_id = -1;
165-
int font_id = -1;
166-
167-
argc = ZEND_NUM_ARGS();
168-
if (argc < 5 || argc > 6 || zend_get_parameters_ex(argc, &image, &text, &font, &x, &y, &color) == FAILURE) {
169-
WRONG_PARAM_COUNT;
170-
}
171-
172-
ZEND_FETCH_RESOURCE(???, ???, image, image_id, "???", ???_rsrc_id);
173-
ZEND_FETCH_RESOURCE(???, ???, font, font_id, "???", ???_rsrc_id);
174-
175-
switch (argc) {
176-
case 6:
177-
convert_to_long_ex(color);
178-
/* Fall-through. */
179-
case 5:
180-
convert_to_long_ex(y);
181-
convert_to_long_ex(x);
182-
/* font: fetching resources already handled. */
183-
convert_to_string_ex(text);
184-
/* image: fetching resources already handled. */
185-
break;
186-
default:
187-
WRONG_PARAM_COUNT;
188-
}
189-
190-
php_error(E_WARNING, "my_drawtext: not yet implemented");
191-
}
192-
/* }}} */
193-
1+
NOTE: ext_skel does no longer exist, it has been replaced
2+
by the PEAR package PECL_Gen

0 commit comments

Comments
 (0)