Re: [RFC] build IDs proposal

From: Date: Wed, 14 Jan 2009 22:29:57 +0000
Subject: Re: [RFC] build IDs proposal
References: 1  Groups: php.internals 
Request: Send a blank email to internals+get-42625@lists.php.net to get a copy of this message
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

« previous php.internals (#42625) next »