Pierre,
I finally took a look at why phar is not built shared as all other
extension. It seems to force it only to be able to be run with no dep
but still uses them if they are lately added (given that phar is now
built statically, that makes little sense). But in fact, it does have
deps against ext/zlib, ext/bz2 and now ext/openssl.
It has *optional* dependencies on all three, yes. Not hard dependencies.
Phar works fine without them, it's just you can't have bz2 compression
without bz2 etc.
You may want to use the library directly but as it will be easy and
problemless for bz2 and zlib, it is going to be a pain for openssl.
Ah, now you understand the problem.
The thing is that direct use equates to "phar needs libeay32.dll". (Not the
other one in my shared-build tests, not sure why.) Now, as you pointed out
earlier, libeay32.dll is bundled with the Windows distro, so in itself that
isn't a problem - people won't struggle to find it. But if phar's built-in,
that gives PHP a hard third-party dependency by default, which is obviously
not acceptable.
The way Greg's written it allows for the openssl extension to be a soft
dependency. If it's not loaded, you just miss that part of Phar's
functionality, and if you want the functionality you need to load
php_openssl.dll. However, if you happen to have built openssl statically
into PHP, you might as well use the underlying library directly, and
currently under Linux that's exactly what happens. That's fine, but it's
also a little odd, since it means the only time you don't use ext/openssl is
when it's there <cough>
Now let's talk about use cases. The way OpenSSL is used in phar is very
minor - just OpenSSL signature verification and creation from existing
private keys. If you want to do any more than that you'd need to load
php_openssl.dll anyway. But most people probably won't want to do any more
than that. Also, if you want to run ext/openssl under Windows you need to
set it up a working environment for it, and this isn't necessary if you just
want to support OpenSSL signatures in ext/phar. So I think we need to offer
the *option* of having a hard dependency on libeay32.dll, with the default
being no dependency. In the config.w32 I posted earlier, the assumption is
that anyone building --with-openssl won't find that hard dependency a
problem, but I'm not sure this is a good idea, especially given that there's
a perfectly good fallback solution.
The other thing we could do of course is throw out all that pure library
code and only offer OpenSSL signature support when ext/openssl is loaded.
That has the benefit of clarity at least.
My main question now is why don't you actually reflect the (optional)
dependencies? bz2 and zlib compression available will not be available
if bz2 or zlib is not present, same for openssl.
What do you mean? In config.w32? No need. In phpinfo()? We already do, just
haven't added the openssl part yet because the configuration's up in the
air.
As testing has_xxx at runtime looks shiny and powerful, I don't think
it is worth the pain.
Sorry, I failed to parse that sentence... :\
Cheers,
- Steph
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
