Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:42625
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 72.14.220.158 as permitted sender)
DomainKey-Status: bad
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=gamma;
        h=mime-version:in-reply-to:references:date:message-id:subject:from:to
         :cc:content-type:content-transfer-encoding;
        b=ps4vPcMED9Dh7uWw3Mlf8mZ4sZfUPDdjqdBHmNSUmxwPVFe5HxDbx2TLANYJa99A/2
         3ffnVo6brUIhXuyk3TvulCYVQRiUvr2LPpxBCrpHhY4ezwrvds1vKNGBMte9UmugLICv
         Hiki91z0Pnr5iJWQpPw50/FrHI+gc49eN9tzw=
MIME-Version: 1.0
In-Reply-To: <496E65B2.1070106@zend.com>
References: <496E65B2.1070106@zend.com>
Date: Wed, 14 Jan 2009 23:29:57 +0100
Message-ID: <fe05d1540901141429h2025b95cw47c75de13f503a98@mail.gmail.com>
To: Stanislav Malyshev <stas@zend.com>
Cc: PHP Internals <internals@lists.php.net>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Subject: Re: [PHP-DEV] [RFC] build IDs proposal
From: pierre.php@gmail.com (Pierre Joye)

On Wed, Jan 14, 2009 at 11:22 PM, Stanislav Malyshev <stas@zend.com> wrote:
> Hi!
>
> As many of you know, one can build PHP engine in a number of ways which are
> binary-incompatible - debug/no debug, thread-safe/not thread safe, etc.
> Also, for windows we have now anther dimension - we could build with VC6,
> VC8, VC9, etc. Loading modules built with another, binary incompatible
> version, could lead to crashes and malfunctions, thus Zend extension and PHP
> extension loaders check these options, stored in special structure, to match
> module ones with engine ones.
> Now the problem is that when we need to add dimensions, we will have to
> change structures and maybe even edit some extensions, and as we have more
> dimensions it becomes less manageable and more "hackish".
>
> I think that it would be better if we adopted more clean and scalable
> solution for that. I propose having one string build ID, which would look
> something like: "API20071006,NTS,Debug,VC8" and would be rquired to match
> exactly in the engine and the module. This should be relatively easy to
> generate when compiling.
> Pro:
> 1. Easy, robust and scalable way to match current and any future build
> flavors
> 2. You can easily create "private" build flavors when testing
> binary-incompatible changes
> 3. Build data is in readable form even inside binary, so binaries could be
> automatically checked by Unix tools.
> Contra:
> 1. Well, it's change :)
>
> What do you think?

As said this morning during our little chat about that, I'm all for
it, the sooner (now) the better.

Another cons:
- if we don't do that, I'll have to add a new element the struct to
indentify which compiler/crt was used to build an ext. That was the
reasons why this proposal comes in now :)


Cheers,
-- 
Pierre

http://blog.thepimp.net | http://www.libgd.org