Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:42624 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 98372 invoked from network); 14 Jan 2009 22:22:47 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 14 Jan 2009 22:22:47 -0000 Authentication-Results: pb1.pair.com smtp.mail=stas@zend.com; spf=pass; sender-id=pass Authentication-Results: pb1.pair.com header.from=stas@zend.com; sender-id=pass Received-SPF: pass (pb1.pair.com: domain zend.com designates 63.205.162.116 as permitted sender) X-PHP-List-Original-Sender: stas@zend.com X-Host-Fingerprint: 63.205.162.116 us-gw1.zend.com Windows 2000 SP4, XP SP1 Received: from [63.205.162.116] ([63.205.162.116:60072] helo=us-gw1.zend.com) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id 43/7D-34613-5B56E694 for ; Wed, 14 Jan 2009 17:22:46 -0500 Received: from [192.168.16.104] ([192.168.16.104]) by us-gw1.zend.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 14 Jan 2009 14:23:34 -0800 Message-ID: <496E65B2.1070106@zend.com> Date: Wed, 14 Jan 2009 14:22:42 -0800 Organization: Zend Technologies User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) MIME-Version: 1.0 To: 'PHP Internals' Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 14 Jan 2009 22:23:34.0339 (UTC) FILETIME=[BCE9F130:01C97696] Subject: [RFC] build IDs proposal From: stas@zend.com (Stanislav Malyshev) 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? -- Stanislav Malyshev, Zend Software Architect stas@zend.com http://www.zend.com/ (408)253-8829 MSN: stas@zend.com