On 14/11/2007, Rob Richards <[EMAIL PROTECTED]> wrote: > Not to drag this on any longer, but here's my 2 cents on this... > > VC 6 builds are not going away any time soon. They work, are well > supported and have gone through years of testing. > > However, eventually the builds are going to have to be upgraded to newer > compilers. > With the changing run times, these are going to need a good amount of > testing, so it would be in our best interest to start putting out some > builds with VS 2005 (or 2008 - pick *ONE*) so that everything (including > working with 3rd party libs) can start being tested, and possibly fixed, > now rather than later. > > For all we know, we'll get lucky and all libs have been optimally coded > so even though they might have been compiled with VC6, VS 2003, etc... > and relying on a different run time they all will work under a VS 2005/8 > build. On the other hand, if there are problems, who here that is > building on 2005/8 tests EVERY function in EVERY extension? We need a > broader audience to test this, so it makes sense to provide a build > (including pecl extensions for that matter). We don't need the builds > updated so frequently right now, but we do need the builds. > > I really don't see what the problem is here. No one here is asking to > replace the official builds right now. We have someone offering to do > the bulk of the work. All she's asking for is some room to put the > builds so that some testing can get started. > > Rob
Hi. It would be useful to see some stats about actual performance increases from using the new runtime. If it is minimal, then cost/benifit isn't great and we are probably going to have to "make-do" for a while on VC6. But, if MSVC2005EE (Microsoft Visual C++ 2005 Express Edition - specifically chosen because of the "free" nature of the product - giving more opportunity to us unfortunates who have to normally pay for all of our development tools to "have a go" at building our own PHP binaries), offers a significant performance increase, then this is the marketing tool we use. Sure, we will have to explain why you need to install a runtime library, but this is windows. Windows users unknowningly install the latest runtime all the time. Many MSI installers have them there simply because that is the safest way to install it and have you app run. Sure it makes the binary package bigger, so you have 2 packages - one with and one without. You make the recommendation that you have the "with" package if you are not sure of the difference. Even at this current time, PHP is relying on the presence of a runtime library. It just so happens that it is so ancient that it is not possible to be on windows without it. So, give 'Liz the space. Please. So those of us who will benefit from her expertise can do so. I really feel that the core developers who only deal with *nix really should allow those that deal with windows be allowed to do so. It has no impact on *nix development other than making code compliant across multiple platforms (a good thing, surely?) As a windows user I feel that we need to move forward and offer another binary which takes advantage of a more modern run time - if the benefit can be expressed. And with all of that, I love PHP. It pays my mortgage. I am happy with it. I just wish I could my patches were accepted easier - http://bugs.php.net/bug.php?id=43261 > > Elizabeth Smith wrote: > > Steph wrote: > >> 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. > >> > > > > I wasn't suggesting replacing the current VC6 builds, I was suggesting > > making 2005 builds available for those who want to test. Since > > linking to a third party distribution site is out of the question > > (which boggles my mind because you DO that for other OS's... Windows > > is somehow held to a higher standard I guess), why can't we provide an > > official download, or heck even a build at snaps.php.net, (in addition > > to the VC6 versions) for the adventurous to use? I would like to find > > edge cases now instead of when 2005 IS the default build - and it will > > happen eventually. And it's quite frankly foolish to ask the windows > > users who want to test to build their own binaries as well, you'll > > never get a windows test bed with that attitude. While on unix and > > linux the "compile it yourself" is standard thought, that is not the > > case and windows and never will be, and all the talks I do on how to > > build on windows can't erase an entrenched mentality. (besides the > > fact that it's just a heck of a lot harder to set up a build system on > > windows) > > > >> 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.) > > > > Actually works fine on 2008 as well ;) The problem is most third > > party libs we link against have windows support as an afterthought - > > no one on the project works on windows or tests on windows and the > > attitude is so negative in the open source (particularly gnu) world > > that the people who DID originally maintain the ports ran away, so the > > build support for MSVC is outdated or missing completely, only people > > who are brave enough to assemble make files or projects by hand and > > fiddle until it builds have success. (Heck, even libxml2 which has > > great official windows build support links against very antiquated > > libiconv - 1.9 released in 2004 when the latest is 1.12) I'd argue > > that this has nothing to do with Microsoft and everything to do with > > Open Source negative stereotypes. > > > >> 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. > > > > This is a good goal, and something I've been working on in general, at > > least assembling open source libraries that PHP extensions link > > against, and building them on different runtimes. But there's no > > place for a "testing area" just for windows that could also distribute > > libs currently on the website. Anyone have ideas for a home for > > this? Maybe a windows section of gcov? Or maybe test 2005 builds on > > snaps.php.net or a page just for binaries for windows? The bottom > > line is the performance increase is enough to justify distributing > > newer builds. > > > >> 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. > > > > Since when is two versions a range...ah semantics... > > > >> 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 > > > > I have one last suggestion that maybe Microsoft (and everyone so > > against the 2005 builds) might want to think about. PHP does not > > distribute binaries for linux and similar distributions, however they > > do provide links to external distribution sites. What's to stop > > Microsoft from distributing non-thread-safe 2005 builds (obviously > > optimized for IIS) on their own servers - and why couldn't the > > downloads page link to that? After all PHP provides the same service > > for other operating systems. In fact, several of the links on the > > downloads page aren't even official builds, but third parties > > providing the software. Is there some kind of issue with third party > > providers not being able to have the same service, just because > > they're for Windows? If it's simply because PHP provides windows > > binaries already...if the binaries are inferior to third party > > offerings... > > > > Anyway, the offer stands to help get libraries up to speed... I'll > > see if I can get a hold of Edin, I have space and bandwidth if that's > > his biggest issue. I could argue with you all night Steph, but it's > > obvious you have an issue with the C runtime changing that Microsoft > > has done with its compilers, and so no matter what I say you won't > > change your opinion ;) Anyone else (other than Steph or Stas) care to > > weigh in? > > > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: http://www.php.net/unsub.php > > -- ----- Richard Quadling Zend Certified Engineer : http://zend.com/zce.php?c=ZEND002498&r=213474731 "Standing on the shoulders of some very clever giants!" -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php