Re: [INTERNALS-WIN] Sorry for the intrusion, but...
[email protected] (Rob Richards)
| Newsgroups | php.internals.win |
|---|---|
| Message-ID | <[email protected]> |
Steph Fox wrote: > > I wasn't trying to start WWWIII. I tried writing to both Rob and > yourself off-list to avoid it, but we're running out of time and I > have had no response. Sorry, I've had a system outage for past 5 days so wasn't getting mail - thank god its finally fixed. You should have gotten bounce backs sending to me. > >>> Can I fix inappropriate usage, or will fixing mean treading on peoples' >>> toes? >> >> No, as I told you already, there is nothing to fix here. So please >> don't change anything in this area. > <snip /> > > > Personally I'd rather have it error out if libxml is missing and xml > extensions relying on it are intended to be part of that build. As you point out it is personal preference. I've had long discussions about this with a number of people as I too was of that opinion originally. There is sense to the madness as it is nice to know everything that is missing rather than having to keep running configure to find them all. > >>> ps Update on the generated .dsp stuff if anyone's interested: >>> everything now >>> *builds* on my box excepting SAPI dlls, which I haven't looked at >>> yet. Also, >>> the welcome discovery that it's possible to convert VC6 project >>> files all >>> the way up to VC9 (and beyond?) from the cmdline means this exercise >>> might >>> not be a complete waste of time after all ;) >> >> We never agreed on that, but if you like to do it, please do but only >> without touching anything else please. Please remove the option for >> configure script and leave it self contained. > > Ye gods. You not only prevent me from joining the doze team from > inception, you're now asking me to disable something others will find > useful for the next several years. Is hating me really more important > than the whole of the PHP project? I see no harm in this piece of code, nor the flag. It can be leveraged until CMake is ready. > >> It is already painful >> enough to deal with the two branches while some only commits to one. > > Some of us merge a heap of stuff to HEAD when it's proven because some > of us don't regularly build HEAD and so won't spot any issues there > arising from hastily-committed and untested code. When the engine in > HEAD works properly and it's possible to test new code there, trust > me, I'll be the first to adopt normal practice. Bring on the day. > That BS. I am sick and tired of hearing that crap. Things should be going to HEAD first and why would you be committing untested code in the first place? If you don't want to commit changes to HEAD when committing stuff to other branches then don't bother committing at all. All you end up doing is making things more difficult for the rest of us. Rob