# [PATCH] win32, PDO and the SQLite build

- Thread: https://externals.io/message/23049
- Original archive: https://news-web.php.net/php.internals/23049
- Started by Steph Fox on 2006-04-30T12:03:39+00:00
- Messages: 3
- Reply by email to internals@lists.php.net
- More for agents: search with https://externals.io/search.md?q={query} · JSON API at https://externals.io/api · documentation at https://externals.io/llms.txt

---

## #23049 — Steph Fox — 2006-04-30T12:03:39+00:00

URL: https://externals.io/message/23049#23049

Hi Wez,

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. If 
ext/sqlite is built as static it 'just works' (forcing a shared build only 
if PDO is enabled as shared) but with the same distinctions, i.e. if there's 
PDO in there it has PDO support, otherwise it doesn't.

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?

I removed the check for php_pdo_driver.h because ext/pdo doesn't check for 
it itself, making the sqlite check fairly pointless as the whole build 
breaks further down the line if the configure line contains --enable-pdo 
when that file's missing.

A small note, in case you didn't notice me banging my head against a brick 
wall on irc earlier - the config.w32 for ext/pdo_sqlite works exclusively 
with pecl/pdo_sqlite at present, whereas the config.w32 files for ext/pdo 
and ext/sqlite both use the version in the PHP extensions directory. 
Probably everyone else in the world is sensible enough to update their PECL 
sources at the same time as their PHP sources, but I'm not, and there's 
nothing to tell you during compilation that the PECL version is actually 
being used. It was only when I finally got it to build (by altering some 
function signature) and found the module wouldn't load due to a PDO API 
version mismatch, that I figured out wtf was going down.

I'll look into this 'not telling us anything' business when I get some time.

I also found - yeah this was a long session - that if the extension you're 
trying to build doesn't exist in your local copy of the PECL directory the 
configure line's simply ignored, even if that extension happens to use the 
sources in the PHP ext dir. This is a separate issue but also needs 
rectifying, and ditto.

The main question I have at present is whether extensions should generally 
be trying to build from the PECL sources, or from the PHP extension 
directory? It should really be either one or the other, particularly for PDO 
and its drivers but also for anything else with a dependency on another 
extension...

- Steph

---

## #23051 — Wez Furlong — 2006-04-30T13:23:33+00:00

URL: https://externals.io/message/23049#23051 · In reply to: #23049

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

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

Rather than bundle, compile and load it twice (it's pretty large), we
simply re-use the code from the sqlite extension.

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.

--Wez.

---

## #23053 — Steph Fox — 2006-04-30T13:53:44+00:00

URL: https://externals.io/message/23049#23053

> 
> > […]
>
> 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 :)

> > […]
>
> 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