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. On 4/30/06, Steph Fox <[EMAIL PROTECTED]> wrote:
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
