[xml] Win32/MSVC Facelift

Hello all.

I have some patches regarding the Win23/MSVC platform and here they are
for your review. Please read the notes at the end of the message.
Please? Pleaseeeee! By the way, this fixes the newly introduced problem
where the compiler claimed it knew nothing about EAGAIN and EINTR.

New Project/Workspace Files

The attached zip file contains the new project files which are different
and therefore incompatible to the old ones. Things that have changed

1. Correct variable export from the shared library.
2. New object file layout which saves disk space and ensures easier
3. Project files for all available test tools, including testCatalog,
testHTML, testSAX, testDocbook, testURI and testXPath.
4. A workspace which includes all project and their dependencies.

The zip file should be extracted into the win32 subdirectory of the
source tree. The project files we have been using so far are untouched
and shall lurk around for a while until we are sure noone needs them

Source patches

The diff against libxml2-2.4.1 is attached to this message and contains
the following changes:

./DOCBParser.c: A trivial change which eliminates the 'wrong parameter
type' warning produced by MSVC. Since this is a warning and not an
error, the diff should be applied only if it is OK with UNIX people.

./include/libxml/xmlversion.h: The LIBXML_DLL_IMPORT macro has been
redefined so it actually works. This change introduces two new macros,
one for libxml and the other for the client code which links against
libxml statically. Both are specific for Win32/MSVC and need not be
considered under other platforms.

./include/libxml/xmlwin32version.h: The same as for xmlversion.h, and
plus brought the file to the same format as xmlversion.h.

./include/win32config.h: Added HAVE_ERRNO_H definition, conditionally
redirected isnan() and isinf() to the implementations found in MS
C-runtime, deactivated trio support, included xmlversion.h for compilers
other than MSVC. Here I assume every C runtime under Win32 provides
errno.h and everyone wants to include xml(win32)version.h. I hope this
is OK with those who use watcom compiler. Mr Jacobi?

./nanohttp.c: A trivial change which eliminates the 'wrong parameter
type' warning produced by MSVC. Since this is a warning and not an
error, the diff should be applied only if it is OK with UNIX people.

./testCatalog.c: Included a missing header file.

./testHTML.c: Removed offending #undef

./testSAX.c: Removed offending #undef

./win32/README.MSDev: Updated to reflect new project file status.


1. xml(win32)version.h

At some point we have given MSVC its very own xmlversion file. I cannot
remember why this has been done, but there has been a reason. Ideally,
we would now remove all WIn32/MSVC-specific stuff from xmlversion.h and
keep it in xmlwin32version.h, but since that stuff still lurks in the
depths of xmlversion.h, I patched it to be correct rather then leaving
it incorrect. Actually, I really don't remember why there are two files.
The library builds equally good with either file and if you take a
closer look, you shall see the files are identical. Can anyone remember
why xmlwin32version.h was introduced?


These two values, which can be read from errno under certain
circumstances, have two different definitions. Once they are defined in
errno.h by Microsoft, the second time in win32config.h by Peter Jacobi.
Peter's definition is correct because it does not redefine anything, it
simply maps to the socket errors. If the other one is correct, is a
topic for argue. However, the two definitions are different and I have
commented out ours, because no code in libxml checks for these errors at
the moment. Stay tuned and listen. If some socket code starts using
these in the future, it shall use the definitions from errno.h and thus
probably check for wrong values. I must think of a way to handle this.

3. isnan(), isinf()

The first of these has a sister in MS C-runtime named _isnan(). The
second one has a, well, half-brother named _finite() which returns
exactly the opposite. Since MS functions know best about MS internal
floating-point oddities and MS reserves the right to change anything
anytime without notice, we should use their runtime functions where

4. trio

I have disabled trio in the Win32/MSVC build. This is not because there
is a problem with trio, but because there is no easy way to
conditionally include a source file in the compilation process with
MSVC. If xmlversion.h is to decide if trio is enabled or not, then we
must compile and link all trio functionality into the executable,
regardless if these funtions actually get called somewhere or not. Since
MS C-runtime provides all string-manipulation functions we need in
libxml, trio is not really necessary. If someone needs trio still, drop
me a note. I must think of a way to include sources conditionally in the
project file and should I get an idea about how to do this in the
meantime, I shall reinclude trio in any event. For now, trio.c is not a
part of the project file and if you #define WITH_TRIO in
xml(win32)version.h, win32config.h is going to #undef it again. Note
that all this happens ONLY when using MS compiler.

5. Binaries

I shall be providing precompiled binaries of libxml for every release
starting tomorrow. Daniel, can these be placed in the contrib directory
on ftp://xmlsoft.org? If yes, how would you like to receive them? Is
email OK, or do you prefer a download location?

6. DSP Files

Now, the new project files are qute different to what a normal
Win32/MSVC developer is used to. I know many of our Win32/MSVC lot whose
habits die hard and who have difficulties when acclimating to anything
that differs from the defaults set by Microsoft. These project files
violate most of those defaults and I stand behind each and every
violation, claiming it is better than the default. If anyone has a
problem with this, a different opinion about how things should be
handled, please contact me. We shall find a solution.

7. Test Utilities

Test utilities, like testSAX, testHTML and friends, are all configured
to link against the static version of libxml. Linking against the
dynamic one shall come shortly, when I figure the problems which occur
on the libxslt side. The dependency to the libxml2_a project is
intentionally left out, so you must first compile libxml2_a and then any
of the utilities. You can use any combination of debug/release when
building the utilities, it does not matter due to the new build process.

8. Thanks

Gigantic thanks for bearing with me. I didn't really believe one would
bring the patience to read all of it :-))

Did I forget something? Hmm.. I hope not. Cheers.

Attachment: dsp.zip
Description: dsp.zip

Attachment: libxml2.diff
Description: libxml2.diff

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]