Re: [xml] mingw configure

["Igor Zlatkovic" <igor zlatkovic com>]

> There was quite a confusion about the MinGW changes in the last
> version of libxml2.
> In the 2.5.10 the configuration of the mingw win32 version has
> changed and it should be reflected/documented somewhere, that you
> can't use the configure.js anymore, but use the MSYS alternative
> shell from www.mingw.org to compile this.

Eh? Well, the Makefile for mingw needs few minor updates, but it is not that
bad. You can use configure.js, just fix the Makefile first ;-)

> And to avoid the confusion (like it caused in my case) I think, that
> "mingw" should be removed as a compiler option in the "configure.js",
> because it doesn't result in something compilable. The "configure.js"
> should be MSVC-only from now one.

Never. Configure.js has been made to support as many compilers as it can
get. If it needs fixing for mingw, then fix it. Or I'll fix it when I get
the time, but I won't drop mingw support.

> It's not my decision to do that, I just wanted to point it out. Sorry
> for the confusion I caused, Daniel and Mikhail.
>
> I also recognised, that there some redundant include paths used for
> compiling after running the configure in MSYS:
>
> gcc -DHAVE_CONFIG_H -I. -I. -I.. -I.. -I.. -I../include -I../include -
> I.    -g -O2 -Wall -c `test -f 'gjobread.c' || echo './'`gjobread.c
> /bin/sh ../libtool --mode=link gcc  -g -O2 -Wall   -o gjobread.exe
> gjobread.o ../libxml2.la  -lz  -lm -lwsock32
>
> 3 times -I.
> 3 times -I..
> and twice -I../include
>
> seems a bit too much of including those paths.

So what? Sometimes it is not easily avoidable, because those compiler
parameters are being generated, not hand-tuned. The compiler won't mind and
will search those direcotires only once anyway.

Ciao,
Igor