Re: A new way for creating extensions

Hey, this looks interesting! I'm catching up on older mail, so I just now saw this. Looks like this could be a great replacement for ext_skel and more. I'll take a closer look in a bit. -Andrei Keisial wrote:

I recently had the need to create a php-gtk extension, and what i found wasn't too pleasant. Most code (gen_*.c) is autogenerated from the defs file by generator/generator.php. Which itself is made by running h2def.py on the C header. Well, it turns out generator/h2def.py is outdated. And by outdated i mean that generator/generator.php *won't be able to process that file*. Oops. The solution is using the newer one maintained by the pygtk folks at http://svn.gnome.org/svn/pygobject/trunk/codegen It also has improvements such as no longer needing to edit the defs file in order to specify which is the constructor. Where to get the other files an extension needs? Well, there's a skeleton extension precisely for a basis for that, right? Wrong! It is also outdated. php_skeleton_register_constants() doesn't expect a module_number, but a const char* Using it you get a nice sigsegv on runtime. Finally, there's ext_skel, a shell script to copy the skeleton dir to the widget's and avoid you the trouble or replacing each skeleton occurrence by the new widget's name. It's also broken, although this may be just in my setup. So, you end up copying one of the working widgets and changing the name in lots of places, with different capitalizations. You invariably forget some, and have to try compiling several times until you get it right. As Bob said when i asked how to create php-gtk extensions, "it is just not very fun to do". That labour would better be achieved by a script, and so i went into making it. This new script resides in generator/ext_gen.php and hooks into the build process, based on ext_data.php on each extension folder. You can use it once to generate the files which you will then customize, or leave them autogenerate on each build. This point is specially interesting because most extensions haven't changed since they were created by copy & replace, and provides a single point of improvement into the system. Also, by keeping the generator in use by a number of extensions, it is guaranteed to be kept up-to-date. Each extension defines a few parameters into the file ext_data.php, and can have most its files autogenerated. The new generated scripts are (expected to be) equivalent to the old ones. In fact, much of it is the same code, to make a cvs diff as smaller as possible. However, there's a number of improvements: -grep | sed process replaced by just a sed -gen_*.h created a bit more independed from gen_*.c -Makefiles actions in one line broken on several. -gen_*.h will include the prototypes of the exported functions of gen_*.c, which would have warned the issue of the register_constants() parameter type at compile time. -php_*.h will include gen_*.h instead of placing the prototypes. -Minor differences on text presented to the user, usually just of capitalization (eg. 'Disable libglade support' vs 'Disable libGlade support'). Transitioned extensions: extra, html, libglade, libsexy Unchanged: gtk+ (lots of special stuff), mozembed (three different modules), scintilla (several customizations), spell (standalone) I have done my best to ensure it doesn't break anything, but any comments are welcome. You can also reach me at #php-gtk. The extensions still build fine on Linux with the patch. On windows, it still fails, as it did without it, so SNAFU. Added files: extra/ext_data.php html/ext_data.php libglade/ext_data.php libsexy/ext_data.php generator/ext_gen.php Modified: win32/buildconf.js build2/build.mk Removed: generator/h2def.py ext/ext_skel ext/skeleton/* [keep skeleton.overrides?] Deprecated: extra/config.m4,config.w32,Makefile.frag,php_gtkextra.c,php_gtkextra.h html/config.m4,config.w32,Makefile.frag,php_html.c,php_html.h libglade/config.m4,config.w32,Makefile.frag,php_libglade.c,php_libglade.h libsexy/config.m4,config.w32,Makefile.frag,php_libsexy.c,php_libsexy.h Renamed (apply manually): mv extra/gtkextra.defs extra/extra.defs mv extra/gtkextra.overrides extra/extra.overrides mv libsexy/sexy.overrides libsexy/libsexy.overrides mv libsexy/sexy.defs libsexy/libsexy.defs Opinions?