Hi Andi, Can I just butt in here for a moment?
Why is everyone in such a rush to get away from the lowest common denominator? Please don't close your eyes to the chief advantage of the lcd build, which is that it works as-is on every Windows version we claim to support. Even on Windows 98 according to user feedback (although I'd love a guided tour of the specific optimizations that break platform compatibility, to get a better idea of where things might fall apart). If we start building the official PHP distro with VS 2005 we're going to have to ship the wretched CRT along with it, or else drop support for everything pre-XP. Is that actually a desired outcome for PHP 5.3? It seems a tad more appropriate, to me at least, to leave that alone until our users stop reporting XP bugs. The build system we use is known to work, out of the box, across all the current MS compiler versions (read: VC6 -> VS 2005 - I'm old-fashioned enough to see 2008 as 'next year'). The only issue, then, is third party libraries. Ergo, all we really need is a 'zip.zip' for each CRT, surely? This assuming - and I guess we do have to assume it - that MS are pushing us into the unhappy position of having to distribute our own builds of third party libs if we want to support Windows at all. (Of course dropping that support would be another option, if possibly not a popular one.) The distribution of third-party libraries is intended for people rolling their own PHP builds. I don't see any justification for distributing more than one CRT version of every PHP release, in fact I think doing so is likely to confuse hell out of most of PHP's end users. The only way it makes any sense is on the 'testing' front - so maybe it'd make sense to ask for volunteer builder/testers on more specialized page(s) used for 'zip.zip' distributions, and set up a bunch of edge case scripts (e.g. stuff that passes around data structures or uses a lot of IO calls, etc). The framework to do that already exists in run-tests.php, although the tests themselves may not. Setting up something this way - a collection of third party libs built with VC7, VC8, VC9 when it arrives - and testing the various library builds with a same-compiler version of PHP in known critical areas, now that would be genuinely useful. That would mean that when (most likely) Apache move on, we're good and ready to move on with them. It concerns me that Edin hasn't been involved either in this discussion or the one a few weeks back, so I'm glad you've been in touch over this issue off-list. I know Elizabeth knows what she's talking about when it comes to VC8 (and probably beyond), and hope she and Edin can come to some sane arrangement. But please hold back with distributing VC8-only versions of PHP when we still support platforms pre-dating its C runtime, and please back off from the idea of offering a range of official PHP builds with different CRTs. It makes absolutely no sense to do either thing at this point in time, and it won't make a great deal of sense to do the latter at any time. nb Andi, Edin's been distributing official NTS builds for some time now... they make a huge difference to CLI, and a visible difference to PHP-GTK's draw speed. And please note, even the 'NTS' option has proved confusing for some...! - Steph On Nov 13, 2007 5:34 AM, Andi Gutmans <[EMAIL PROTECTED]> wrote: > Hi Elizabeth, > > No doubt there's value in providing a non-threadsafe build of PHP as now > that there's a robust and efficient FastCGI solution for IIS which is > likely to be the preferred way to run PHP on Windows. Also, we know PHP > runs significantly faster when built with Visual Studio 2005 (VC8) and > one of the optimizations we made in the source is even VC8 specific as > the functionality didn't exist with the previous version. > Basically we should have the same package as today and have an > additional package which is non-threadsafe with VC8 (we offer a separate > package for releases anyway). > > I've actually had this discussion a few days ago with Edin and John > (Windows Installer). They were also supportive but I guess it's mainly a > bandwidth issue for Edin. So if you can connect with him and help make > it work that'd be great. We can also help out with the process as we've > been successful in doing such a build. > > Thanks for stepping up! > Andi > > > > -----Original Message----- > > From: Elizabeth Smith [mailto:[EMAIL PROTECTED] > > Sent: Monday, November 12, 2007 9:09 AM > > To: internals@lists.php.net > > Subject: [PHP-DEV] Providing Visual Studio 2005 builds (again) > > > > Afternoon, > > and don't shoot me, > > > > I'd like to bring up the topic of providing builds created with Visual > > Studio 2005 again. I know that until Apache and other Open Source > > software makes the move as well, we can't provide ONLY 2005 builds > > because they just won't work properly, the runtimes will crash and > > things will blow up. > > > > But what is the thought of providing additional builds? I'm thinking > > specifically of Windows users running FastCGI probably on IIS with a > > non-threadsafe build (implying that they're not point and click > > installer happy already, and therefore a step above the general > > population), who would get the most performance increases out of the > > switch to the new compiler. So basically a special non thread safe > and > > 2005 compile for additional download. I'm well aware that the process > > of doing this needs to be well thought out and planned, but PHP users > > are notorious for not testing things that aren't available right on > the > > downloads page, and people at Microsoft have made the request that > > binaries be made available on the php.net site. > > > > I'd be willing to help create builds of common open source libraries > > that PHP links against, such as libiconv and libxml2, with the newer > > compiler so there are no runtime issues originating from that angle. > > But until people start using it, we can't really see where issues are > > going to appear. And I know it will be a big job to get all the open > > source libraries php extensions link against migrated to the new > > compiler (and impossible for the closed source ones) - but I think we > > need to be proactive in this and not sit around until Apache migrates > > and then have everything break ;) > > > > Opinions? Thoughts? And yes I am volunteering to help with the work, > > not just whining for a solution. > > > > Thanks, > > Elizabeth Marie Smith > > > > -- > > PHP Internals - PHP Runtime Development Mailing List > > To unsubscribe, visit: http://www.php.net/unsub.php > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: http://www.php.net/unsub.php > > -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
