On Mon, Jun 23, 2008 at 1:28 PM, Steph Fox <[EMAIL PROTECTED]> wrote:
> You're missing that Windows users don't tend to roll their own PHP. They
> tend to pick and choose their extensions.
I still miss your point here, I was only talking about bins releases
for windows.
> At present, if someone were to load php_openssl.dll from PECL
>From PECL? it is in our releases and will remain in our releases,
just like all extensions.
> alongside
> built-in Phar in 5.3 they'd probably wonder why it wasn't working as
> advertised. If the dependency were made explicit in Phar, the only thing
> ext/openssl would be needed for is explicit openssl calls - which is far
> easier to understand.
--enable-phar-ssl and do (not tested but it gives the idea):
if (PHP_PHAR_SSL == "yes") {
ADD_EXTENSION_DEP("phar", "openssl", true);
} else {
if (PHP_PHAR_SSL != "no") { // be sure to do not enable it when
--disable-phar-ssl is used
ADD_EXTENSION_DEP("phar", "openssl", true);
}
}
> FWIW, I think having Phar built-in is actually a disadvantage when it comes
> to this kind of thing. ext/openssl isn't enabled by default and is only
> available as shared to the vast majority of Windows users.
it is enabled by default and it is built shared as almost all
extensions. The rest is a matter of documenting it, like almost all
extensions, "please enable phar and openssl (if available) in your
php.ini".
Cheers,
--
Pierre
http://blog.thepimp.net | http://www.libgd.org
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
