hi François,
On Wed, Jan 7, 2015 at 2:14 PM, François Laupretre <franc...@tekwire.net> wrote: >> De : Pierre Joye [mailto:pierre....@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. Or let the extension defines a script to prepend, preload, whatever we end to do. It is however important, as you mentioned, to leave the engine and the user the ability not to load it, at all. >> 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. Indeed, but I did not refer to separate releases here but the ability for Composer to install extension. If a script is part of an extension release, it will be installed as well. > 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). I suppose you mean to the extension PHP code, right? That's what is done already for include_path for example. It has to be system and optionally loaded. > 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 ? Yes, and it is very easy to do and maintained. At least compared to bundling script into binaries. Our build scripts already support installing custom files out of the box for example. > 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 ? It is up to the maintainers. I would not do separate releases as it makes it hard to track or support. Doing more releases even to "only" fix the PHP glue codes sounds like a good practice anyway. Cheers, -- Pierre @pierrejoye | http://www.libgd.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
