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
>