RE: [PHP-DEV] [RFC] Extension Prepend Files

> De : Pierre Joye [mailto:pierre.php@gmail.com] > > ... here, > it is proposed to bundle scripts that will be executed at runtime like any > other script, except that nothing can be done with them, not even disable > them if not required (like using its own glue codes). I agree. Bundling scripts in extensions to execute them at each RINIT is, IMO, not a good idea (mostly for performance reasons and lack of control, as you note), but I keep thinking that a mechanism to embed PHP scripts in extensions and make them available via a common stream wrapper can be useful. What I don't like is the fact to execute them automatically at every RINIT. I prefer to let the extension free to load its PHP code when its logic decides it is needed. > Pickle integration is almost finished, that solves your worries about composer and pecl > extensions. Both mechanisms can coexist. They are not incompatible and probably fulfill different needs. You are asking for a standard path for plain files linked to an extension. As putting the shared library and plain files together is not a good idea, what about something like this : <php-install-prefix>/lib/php/extensions/php/<extension-name> A C macro can be defined to provide the path to the extension C code, in order to avoid hardcoding it (this way, it could be modified in the future). At install time, we could say that every files under <extension-source-dir>/php/install, if this dir exists, are installed there. It is just an example but does it correspond to the mechanism you were thinking about ? What is not clear to me is the question of packaging/versioning/deployment. If you consider the PHP glue code is modified more often than the C code, which will be the most frequent case, how do you version/distribute partial packages ? or do you deliver 2 packages with independent versioning and dependencies together ? In this case, should we define a versioning convention for both packages ? Regards François