[xslt] Windows build

[Igor Zlatkovic <igor stud fh-frankfurt de>]

Hi,

I have done the announced modifications and everything is commited in the
CVS.

1. The Windows CE patch from Javier is commited, so libxml now runs on all
handhelds with Windows CE.
2. Both libxml and libxslt now compile the library source twice, producing
two sets of object files. The one is used to build the static libs, the
other to build the dynamic libs.
3. WinSock compatibility macros are oursourced in their own file, called
include/wsockcompat.h.

Number 2 has resolved several link issues with other libraries. For example,
imagine someone would build Aleksey's xmlsec and link to libxml statically.
Then she would make a program based on that xmlsec, but also call into
libxml, and then link to xmlsec statically, to libxml dynamically. This case
would give a myriad of linker warnings about multiply resolved symbols,
because the executable would have libxml symbols twice, once from the
dynamic libxml, once from the xmlsec. This is not a real problem, as the
program will link and work properly, but the double-run removes that warning
lot. By the way, xmlsec now builds in the same way.

Number 2 has increased the build time, that is clear. However, as expected,
it is still needs less time to build on Windows than it needs on Linux. I
therefore consider the build time more than acceptable.

Number 2 makes the build immune to whichever export mechanism people agree
on. We can agree on putting a LIBXML_PUBLIC macro in the declaration of
every exportable thing, or on keeping the current .def.src mechanism. That
decision I now must leave to others, as it is just a matter of preference on
my platform. Windows/MSVC build will now work either way. Xmlsec, for
example, does not use the .dev.src approach and has an identical Makefile.

Number 3 is the first step in allowing mingw build to use GNU autoconf
facilities. More will be necessary before this works, however I have no
means to fix the GNU autoconf things (like configure.in and friends) here,
others will have to do that.

What I could do now to ease it a bit is to remove win32config.h completely
and have the source include config.h, just like on Unix. That would
eventually allow mingw users to choose between two configuration mechanisms
and use either the JScript-based one (does not need an Unix shell on
Windows), or a GNU autoconf based one (the only way for an Unix-hosted
cross-compiler).

That would however require a configuration stage, either one, in order to
generate the apropriate config.h. I know of one person who can execute
neither, namely Peter Jacobi on his good ol NT4 box. I would therefore need
some feedback on if and how to acomplish this so everyone is happy.

Ciao
Igor