Re: [INTERNALS-WIN] Sorry for the intrusion, but...

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.

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.

Don't you think somebody would have noticed some time in the last 5 years if the problem this tries to fix actually existed?

When a dep check is done, it is necessary to know if it succeeded or not, not visually (message printed out) but in the script.

I have no idea what you're trying to say here. Are you suggesting that PHP doesn't 'know' about the dependency otherwise?

It is easy to check with the DOM extension, simply try a snap build with no library but bindlib in the dep path.

'Simply waste 3 hours' because...? OK, here's a quicker way. This is ext/dom/config.w32: ARG_WITH("dom", "DOM support", "yes"); if (PHP_DOM == "yes") { EXTENSION("dom", "php_dom.c attr.c document.c domerrorhandler.c \ domstringlist.c domexception.c namelist.c processinginstruction.c \ cdatasection.c documentfragment.c domimplementation.c element.c \ node.c string_extend.c characterdata.c documenttype.c \ domimplementationlist.c entity.c nodelist.c text.c comment.c \ domconfiguration.c domimplementationsource.c entityreference.c \ notation.c xpath.c dom_iterators.c typeinfo.c domerror.c \ domlocator.c namednodemap.c userdatahandler.c"); ADD_EXTENSION_DEP('dom', 'libxml') AC_DEFINE("HAVE_DOM", 1, "DOM support"); } In the makefile following "--enable-snapshot-build" (or even just "--enable-debug"), I see: STATIC_EXT_CFLAGS=$(CFLAGS_BCMATH) $(CFLAGS_CALENDAR) $(CFLAGS_COM_DOTNET) $(CFLAGS_CTYPE) $(CFLAGS_DATE) $(CFLAGS_EREG) $(CFLAGS_FILTER) $(CFLAGS_FTP) $(CFLAGS_HASH) $(CFLAGS_ICONV) $(CFLAGS_JSON) $(CFLAGS_MYSQLND) $(CFLAGS_ODBC) $(CFLAGS_PCRE) $(CFLAGS_REFLECTION) $(CFLAGS_SESSION) $(CFLAGS_SPL) $(CFLAGS_STANDARD) $(CFLAGS_TOKENIZER) $(CFLAGS_ZIP) $(CFLAGS_ZLIB) $(CFLAGS_LIBXML) $(CFLAGS_DOM) $(CFLAGS_SIMPLEXML) $(CFLAGS_WDDX) $(CFLAGS_XML) $(CFLAGS_XMLREADER) $(CFLAGS_XMLWRITER) If I try "--without-libxml" the build fails: Enabling extension ext\dom ERROR: Cannot build dom; libxml not enabled So we know if the dependency is there or not, and if ext/dom happened to be built as shared rather than static that would just be a warning. The version currently in CVS merely gives a warning as it disables part of the core: STATIC_EXT_CFLAGS=$(CFLAGS_BCMATH) $(CFLAGS_CALENDAR) $(CFLAGS_COM_DOTNET) $(CFLAGS_CTYPE) $(CFLAGS_DATE) $(CFLAGS_EREG) $(CFLAGS_FILTER) $(CFLAGS_FTP) $(CFLAGS_HASH) $(CFLAGS_ICONV) $(CFLAGS_JSON) $(CFLAGS_MYSQLND) $(CFLAGS_ODBC) $(CFLAGS_PCRE) $(CFLAGS_REFLECTION) $(CFLAGS_SESSION) $(CFLAGS_SPL) $(CFLAGS_STANDARD) $(CFLAGS_TOKENIZER) $(CFLAGS_ZIP) $(CFLAGS_ZLIB) 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.

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?

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. - Steph

-- Pierre http://blog.thepimp.net | http://www.libgd.org -- Windows Internals Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php