Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:64992
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.210.176 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <fbb3c62c5a8f.50f57029@blastwave.org>
References: <fbb3983e29af.50f46792@blastwave.org>
	<50F4CE6B.5060809@oracle.com>
	<alpine.DEB.2.02.1301151036140.28951@whisky.home.derickrethans.nl>
	<fbb3c62c5a8f.50f57029@blastwave.org>
Date: Wed, 16 Jan 2013 09:40:57 +0100
Message-ID: <CAH-PCH7XkUXiK9pC9-rxDPRCQR3m18tGcmf0CMAgag7YvQXKsA@mail.gmail.com>
To: Dennis Clarke <dclarke@blastwave.org>
Cc: Derick Rethans <derick@php.net>, Christopher Jones <christopher.jones@oracle.com>, 
	PHP Internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary=20cf303346134d9d1a04d363d6c7
Subject: Re: [PHP-DEV] PHP 5.4.10 can not build Zend/PHP parsers with bison 2.6.5
From: tyra3l@gmail.com (Ferenc Kovacs)

--20cf303346134d9d1a04d363d6c7
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

On Tue, Jan 15, 2013 at 9:05 PM, Dennis Clarke <dclarke@blastwave.org>wrote=
:

>
> > >
> > > Unless you are hacking PHP you can ignore Bison. Check the Makefile
>
> Well, the configure output claims that something is wrong, therefore the
> build can not be trusted.
> I'm just following the defacto way to build PHP and if the configure
> output claims
> something is wrong .. then it is wrong by definition.
>
> > > for where it is used.  The PHP distribution contains
> > > Zend/zend_language_parser.[ch] and php-5.5/Zend/zend_ini_parser.[ch]
> >
> > > already built from their respective .y files so bison is not
> > generally invoked when building PHP.
>
> configure claims otherwise.
>
> > > Of course, if 2.6.5 is verified than it should be added to
> > > bison_version_list in Zend/acinclude.m4.  Feel free to regenerate
> > the
> > > parsers with it, review the test suite results, and create a github
> > > pull request.
>
> do what ?  I access the release source tarball only.
>
> gcc-spec_node002 $ digest -a sha1 /usr/local/src/php-5.4.10.tar.gz
> 6be6a1c16ca3f6bec93d19ce5d6b94c5cf89373b
>
> That is the only php sources I am allowed to use. Anything else is not
> "release" and
> therefore not to be used on prod servers.
>
> >
> > I think we should retire this silly check, as it needs updating every
> > time there is a new version. Instead, we should blacklist versions
> > that *don't* work.
>
> Well bison 2.6.5 passes all of its own tests and therefore seems to be
> "okay for prod".
>
> I would think that a PHP release would build more or less out of the box
> without any
> changes to the source tarball.  If PHP can not be built from the release
> tarball with
> the typical GNU toolchain then .. it can't be built.  I just tick off a
> box on the build
> sheet here as "does not build in compliance with defacto standard rules"
> and it goes
> back onto the "update at some point" pile.
>
>
currently we have a whitelist for supported bison versions:
http://lxr.php.net/xref/PHP_5_4/Zend/acinclude.m4#6
anything else will be reported, but this doesn't mean that php wouldn't
compile with that, it can also mean that nobody tested and made sure that
it works.
this is why Derick mentioned that he thinks we should switch to a
blacklist, so we only report the versions with known problems.

ps: your passive aggressive tone doesn't really help your case here.

--=20
Ferenc Kov=C3=A1cs
@Tyr43l - http://tyrael.hu

--20cf303346134d9d1a04d363d6c7--