Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:23058
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws;
	s=beta; d=gmail.com;
	h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references;
	b=jAvp+MgR2sFhpMHp828EXQBKFDxjGYrB6JAi/3fgwnzisIlnQaNNM0SjWHRBJKl2h/1v5xcDizURB0ogPPD1gTIS8OgT7cdnaJw33xYe0ChWVMPApOQonlPTvZ4hHqd3p3sAja0VpWboeevDBfoepHC0Gp6s4HH9DXCO4Gkp3vo=
Message-ID: <4e89b4260604301615v60291d94q951020d4dbe5a34d@mail.gmail.com>
Date: Sun, 30 Apr 2006 19:15:55 -0400
To: "Steph Fox" <steph@zend.com>
Cc: internals <internals@lists.php.net>
In-Reply-To: <0ca501c66c6e$a0f1a070$6602a8c0@foxbox>
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline
References: <0ca501c66c6e$a0f1a070$6602a8c0@foxbox>
Subject: Re: Fw: [PATCH] win32, PDO and the SQLite build
From: kingwez@gmail.com ("Wez Furlong")

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 <steph@zend.com> wrote:
> Wez, I know you're busy, but this isn't some beginner trying to figure ou=
t
> 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 th=
e
> 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 developm=
ent
> area, then a PECL extension released with/alongside a PHP distro should b=
e
> the current stable release appropriate to that PHP version, and whether i=
t'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 an=
d
> 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 an=
d
> 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 branc=
h
> (regardless of its development status), and every extension not regarded =
as
> reliably stable _needs_ to be built as shared - whether this happens to b=
e
> as part of a PHP distro build or not. (But if that was the idea, what wou=
ld
> be the point in shipping any PECL extension as part of the PHP core distr=
o?)
>
> Short version: I think we're having a clash over intent here. It'd be han=
dy
> to know what yours is, given that you're running the show :)
>
> - Steph
>
>
> >> On 4/30/06, Steph Fox <steph@zend.com> 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. Thi=
s
> > 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 n=
o
> > answer, I assumed it was because it's still marked EXPERIMENTAL - and i=
n
> > 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 libr=
ary
> > 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 wh=
at
> > users are used to; I think SQLite, having been there before, should nev=
er
> > 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 fo=
r
> > people to remember when they're enabling their chosen PDO drivers.
> > PDO_SQLite should also be in there because people should be moving to i=
t,
> > 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 probl=
em
> > with the status quo. What arguments are there against built-in database
> > support, other than 'we ship all the binaries anyway'?
> >
> > - Steph
>
>