Re: [INTERNALS-WIN] Lib queries - dirent

[email protected] ("Steph Fox")
Newsgroups php.internals.win
Message-ID <01b201c961fc$d02617a0$3ffc1f3e@foxbox>
> This layout has one big advantage, you can't mix builds. At the very
> least, if you know what you are doing and will always use a single CRT
> (which is going to change pretty soon in your case for example), then
> you simply have to do one more "cd vc6\x86" et voila. Nothing that can
> justify to propose an alternative layout. Feel free to do it ( :) )
> but please do not document it or do not add it to the wiki.

The whole thing of doubling up on CRTs is very much on the side of the 
person doing the releases, not extension developers (or even core 
developers) - not at this stage, and probably not ever. People still have a 
choice between VC 9 and VC 6 for the lifetime of PHP 5.3, as I understand 
it, and it's VC 9 only thereafter. I won't be making the move until I have a 
new laptop, and if MS do their funny 'is it a real Windows machine' check on 
the VC 9 download I probably won't be able to do it even then. But when I 
_do_ make the move, I won't have a VC 6 environment on the same box anyway.

I doubt very much I'm alone in this - not least because most of the core 
devs aren't primarily Windows developers.

The reason I'm considering an alternative layout is simply to get rid of the 
duplication caused by setting up an entire development environment for each 
PHP version. Well, and also the fact that I currently throw anything else 
I'm working on into the same environment anyway, so include is always 
include, lib is always lib, bin is always bin - most projects expect this 
layout.

If your development environment is *only* used to build PHP and you have 
plenty of space, sure, do everything in triplicate, why not? I'm not 
suggesting to replace that, just mentioning that there should be another, 
simpler way to achieve the same result.

- Steph
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.