# Fw: [PATCH] win32, PDO and the SQLite build - Thread: https://externals.io/message/23054 - Original archive: https://news-web.php.net/php.internals/23054 - Started by Steph Fox on 2006-04-30T15:56:21+00:00 - Messages: 5 - 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 --- ## #23054 — Steph Fox — 2006-04-30T15:56:21+00:00 URL: https://externals.io/message/23054#23054 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 > > […] > > 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'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. > > > […] > > 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 --- ## #23058 — Wez Furlong — 2006-04-30T23:15:55+00:00 URL: https://externals.io/message/23054#23058 · In reply to: #23054 Can you distill the problem to one paragraph or less? I'm having a hard time figuring out what you're getting at. 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. > 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 > > > > […] --- ## #23059 — Steph Fox — 2006-05-01T00:07:25+00:00 URL: https://externals.io/message/23054#23059 > 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. --- ## #23060 — Wez Furlong — 2006-05-01T00:21:03+00:00 URL: https://externals.io/message/23054#23060 · In reply to: #23059 > > […] > > 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. It's nothing that can't be solved by some good documentation. > 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. The whole point of PECL is that its lifetime is completely independent of PHP. --Wez. --- ## #23061 — Steph Fox — 2006-05-01T00:32:20+00:00 URL: https://externals.io/message/23054#23061 > 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.