Wez, I know you're busy, but this isn't some beginner trying to figure out
how to use their php.ini, y'know?
At present there are some PDO drivers relying on PECL source, and others
relying on their php-src/ext directories. All that does is mess up builds
where PHP and PECL are out of sync. It needs to be either one or the
other... given that this is the most recent PHP distro (5.1.3) 'out of the
box', which should it be?
Basically this - and the matter of built-in anythings - comes down to the
question of the way PECL is viewed. If it's intended purely as a development
area, then a PECL extension released with/alongside a PHP distro should be
the current stable release appropriate to that PHP version, and whether it's
built as static or not shouldn't be considered majorly important. In that
scenario, the snaps box should be clearly marked as a development tool and
should _only_ build shared extensions, using a current PECL CVS branch
corresponding to the appropriate PHP CVS branch. The only time most PHP
users would know snaps even exists would be when they'd reported a bug and
were testing a fix for it.
On the other hand, if the intention is that it should always be possible for
users to upgrade extensions via the snaps box without also upgrading PHP,
then the PHP build _needs_ to be synched with the relevant PECL CVS branch
(regardless of its development status), and every extension not regarded as
reliably stable _needs_ to be built as shared - whether this happens to be
as part of a PHP distro build or not. (But if that was the idea, what would
be the point in shipping any PECL extension as part of the PHP core distro?)
Short version: I think we're having a clash over intent here. It'd be handy
to know what yours is, given that you're running the show :)
- Steph
On 4/30/06, Steph Fox <[EMAIL PROTECTED]> wrote:
The attached patch makes it possible to build either php_sqlite.dll
without
the PDO dependency, or php_pdo_sqlite2.dll with the PDO dependency.
That means that you end up with php_pdo_sqlite2.dll only in the
official snapshot builds.
Yes - because it has PDO support. That's exactly the same situation we
already have in win32 snaps, except that it doesn't declare itself. This
way it _does_ declare itself, removing a tiny bit of WTF-ness from the
lives of win32/PHP users everywhere :)
I'm hoping it'll mean you can consider enabling built-in sqlite by
default
again, even if PDO isn't quite ready for that yet?
It's got nothing to do with PDO "being ready". The only reason that
the sqlite2 driver is part of the sqlite2 extension is because we
include a bundled sqlite2 library.
I've asked several times why PDO isn't enabled by default. Having had no
answer, I assumed it was because it's still marked EXPERIMENTAL - and in
fact that's the only answer anyone else could come up with too.
I still don't see why you think that you need everything to be
compiled into PHP statically on windows--we ship *all* the binaries
that you might need, and everybody knows how to edit php.ini to turn
on the bits they are missing.
Everybody knows you HAVE to enable PDO in order to run SQLite 2 in PHP
5.1, despite the fact that SQLite 2 was statically built-in throughout the
5.0 series and despite the fact that there's nothing in the sqlite library
name to make that relationship obvious? Are you sure?
I don't want *everything* to be statically built in. I think having no
built-in database support in PHP is basically wrong because it's not what
users are used to; I think SQLite, having been there before, should never
have been removed in the way it was in the first place; and I think PDO
should be statically built-in by default because it's one less thing for
people to remember when they're enabling their chosen PDO drivers.
PDO_SQLite should also be in there because people should be moving to it,
but SQLite 2 - being used in PHP 4 code as well as PHP 5 code - should be
supported, and this seems the best way of ensuring that it always is.
The part I really don't understand is why you don't see there's a problem
with the status quo. What arguments are there against built-in database
support, other than 'we ship all the binaries anyway'?
- Steph
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
