Pierre,
I must be going crazy. Is there an actual problem that needs solving?
You're saying that a user who improperly installs php_openssl.dll (i.e.
does not follow instructions and set up ssleay.dll and libeay.dll) should
magically be able to use phar with openssl? Why?
You are not going crazy, I was asking the same in my very first reply.
Odd, that. I have nothing in my ML archives mentioning this imaginary poor
confused user until Greg's post.
The only thing I like to see in config.w32 (and config.m4 too if
possible) is the dependencies definition. As it has no impact at
runtime (as you explained), it can be used at configure and build time
to check than the right extension or libraries are used. Or at least,
to notify the user than running configure with --disable-all
--enable-phar is not enough to give bz2, zlib or ssl support.
I think you're becoming very confused about the distinction between
developers and users. Most users running PHP under Windows do *not* build
their own copy of PHP. The rest of us don't need PEAR-type config output
styling etc, we can read standard configuration output thanks. --disable-all
is so rarely used under doze that until I fixed it last week, it hadn't ever
worked. In 5 years (more?) there was only one complaint - from Hector, who
was trying to roll his own PHP for distribution, which is discouraged. Even
nmake clean is reserved for distribution/snapshots builds, and we didn't
have an alternative for it in local builds until very recently. There just
aren't enough people working on PHP under Windows for these things to have
been a real problem. The ones that do, don't build PHP in the way you
anticipate here. The people that build PHP like that are *nix users.
PHP/Windows *users* use phpinfo() and php -m to find out what they have on
board. phpinfo() explains what is or isn't available in Phar and what is
needed to enable it. They don't need more than this. Are you really
suggesting that developers need more info than this because they're less
able to read than end users are?
Finally, as Greg has already tried to explain, in Phar the dependencies are
100% soft. Building phar alongside bz2 doesn't trigger bz2 functionality,
but loading bz2.so does. There's absolutely no association between the
configure line and the support offered. The one exception here is the
phar-ssl stuff I committed for Windows yesterday, which is fairly likely to
disappear altogether once Greg has had time to think it through properly
because it doesn't really make sense, given our normal context, to offer
built-in functionality in that way.
- Steph
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
