Fw: [PATCH] win32, PDO and the SQLite build View as Markdown

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

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

Can you distill the problem to one paragraph or less? I'm having a
hard time figuring out what you're getting at.

OK, I'll work on it.

Initial/primary argument here: under Windows, to load one extension that I
would have had as an integral part of 5.0.*, I now need to install two
extensions via php.ini, and it's not evident (without reading the manual -
and why would you, to install a simple upgrade?) that there's been any
change.

I realize this is not an issue for the cognescenti, but I think it might be
a problem for people trying to figure stuff out - and I'd also submit the
vague idea that a lot of the people trying to figure stuff out might be
win32 users.

Secondary argument is as a result of your responses to my initial bleh:

You need to decide whether PECL is intended as a laboratory with stable
releases that become part of the PHP distro, or an integral part of PHP at
all developmental stages.

• Steph

I don't see a problem with the current status of the PHP win32 build
that can't be resolved by loading the extensions that you want to use
in php.ini.

--Wez.

The whole point of PECL is that its lifetime is completely independent of
PHP.

Right. Now will you please go back to the questions I originally asked?

| 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.
|

--Wez.